

Introducere

Vă mulțumim că ați cumpărat această carte. Sperăm să vă distrați la fel de mult citindu-l pe cât ne-am făcut noi în scrierea lui și că reușiți să găsiți tot atâtea lucruri utile cât am găsit noi la compilarea lui. Obiectivele din spatele acestei cărți au suferit schimbări considerabile între începuturile ei (la grupul olandez de utilizatori „Conference to the Max” ținută la Arnhem, Olanda în mai 1999) și versiunea textului pe care o țineți acum în mâini. Cu toate acestea, paragrafele de mai jos descriu ceea ce am sperat în cele din urmă să realizăm cu cartea.

Ce este această carte?

În primul rând, trebuie menționat că aceasta nu este o carte care vă va învăța cum să utilizați Visual FoxPro. Obiectivul nostru principal a fost să încercăm să distilăm unele dintre experiențele (deseori dureroase) pe care noi și mulți alții le-am acumulat de-a lungul anilor, astfel încât să puteți evita să cădeți în aceleași capcane pe care le-am făcut noi și poate chiar să găsiți câteva modalități alternative de facand lucruri. Acest lucru nu înseamnă că există întotdeauna un mod „cel mai bun sau chiar „corect” de a face lucrurile în FoxPro. Limbajul este atât de bogat și puternic încât există, de obicei, mai multe moduri de a aborda orice problemă, cu toate acestea, există și multe capcane pentru cei neprudenți și multe tehnici care s-au dovedit utile. Problema pe care am încercat să o rezolvăm este să colectăm astfel de trucuri și capcane împreună, să le grupăm într-o ordine logică și să încercăm să furnizăm singurul lucru pe care aproape fiecare dezvoltator pe care îl cunoaștem l-a cerut - exemplu de cod concis și „relevant” .

Câteva cuvinte despre codul din această carte

Exemplele de cod din această carte au fost scrise în mod conștient pentru a le face ușor de urmărit - uneori, acest lucru a însemnat că am renunțat la unele optimizări evidente. Astfel, veți găsi multe locuri unde ați putea spune „De ce nu au făcut-o așa? Ar fi salvat o duzină de linii de cod! Vă rugăm să aveți grijă de noi și amintiți-vă că nu toată lumea este la fel de perceptivă ca tine.

Veți observa, de asemenea, că, din motive similare, nu am repetat, în fiecare fragment de cod, metodă sau funcție, testele „standard” și codul de gestionare a erorilor pe care v-ați aștepta în mod normal să le găsiți (cum ar fi verificarea tipului de parametri transferați unui funcţie). Am presupus că știți cum să faceți acest lucru și, dacă doriți să utilizați codul din această carte, îl veți adăuga singur acolo unde este necesar.

Deci pentru cine este această carte?

După cum am spus deja, această carte nu vă va învăța să utilizați Visual FoxPro - presupune că aveți un grad rezonabil de confort cu funcționarea de bază a bazei de date VFP și a limbajului de comandă și cu principiile de bază ale programării orientate pe obiecte. Ne-am aștepta să fi citit și folosit referințe excelente și utile precum „Programming VFP” al lui Whil Hentzen, „The Revolufionary Guide for VFP OOP” de Will Phelps, Andy Kramek și Bob Grommes și, desigur, indispensabilul „Hacker’s Guide”. pentru VFP' de Tamar Granor și Ted Roche.

Dacă sunteți în căutarea unor modalități alternative de abordare a problemelor, indicii de îmbunătățire a codului, soluții pentru capcanele obișnuite și „povești de război” ale celor care au fost acolo și au făcut-o (da, avem chiar și tricourile), atunci această carte este pentru tu.

Ce este în această carte?

Această carte include soluții încercate și testate la probleme comune din Visual FoxPro, împreună cu câteva tehnici de bază pentru construirea instrumentelor și componentelor Visual FoxPro. Cartea este organizată în

capitole care încearcă să grupeze subiectele sub titluri logice. Fiecare capitol constă, în esență, dintr-o serie de „Cum fac ..?” întrebări. Fiecare întrebare include un exemplu de lucru, iar exemplul de cod al fiecărui capitol poate fi descărcat individual.

Toate exemplele de cod au fost scrise și testate folosind Visual FoxPro Versiunea 6.0 (cu Service Pack 3). Deși o mare parte din el ar trebui să ruleze în orice versiune de Visual FoxPro, există, evident, unele lucruri care sunt specifice versiunii. (Fiecare versiune nouă de Visual FoxPro a introdus câteva comenzi și funcții complet noi în limbaj.)

Ce nu este în această carte?

O mulțime îngrozitoare! Pentru a menține această carte la o dimensiune acceptabilă, am omis o mulțime de lucruri. Deoarece aceasta este în esență o carte „Cum să” pentru Visual FoxPro, nici măcar nu am încercat să acoperim subiecte precum construirea de componente COM sau pagini web de Internet (există cărți excelente despre aceste subiecte disponibile). Nici nu am acoperit controalele ActiveX sau Automatizarea (ar fi nevoie de o altă carte doar pentru acest subiect). Recunoaștem că există omisiuni semnificative, dar am simțit că, deoarece nu am putea acoperi totul, ar trebui să ne concentrăm asupra problemelor „pure” Visual FoxPro - și nu ne cerem scuze pentru acest lucru.

De unde începi?

Răspunsul scurt este oriunde doriți! Deși una dintre preocupările noastre principale a fost să facem din aceasta o carte „lizibilă”, recunoaștem că probabil vă uitați la această carte deoarece aveți o problemă specifică (sau poate mai multe) cu care să vă ocupați și sunteți în căutarea inspirației dacă nu o soluție reală. Nu putem spera să oferim „soluții” tuturor, dar dacă vă putem oferi puțină inspirație, susținută de un exemplu de cod pentru a începe, atunci ne vom fi reușit în obiectivele noastre - și vă puteți relaxa știind că cheltuielile dvs. modeste pe acest volum sa dovedit deja o investiție utilă.
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Dedicații

Andy Kramek

Această lucrare este dedicată tatălui meu, care a fost atât de mândru când am început să am o parte din scrierile mele publicate, dar a murit cu puțin timp înainte de finalizarea acestei, cea mai recentă carte, despre care știu că l-ar fi făcut și mai fericit.

Marcia Akins

Surorii mele Nancy, care m-a învățat că niciodată nu este prea târziu să încerc și fără ajutorul căreia nu aș fi putut face tot ce am în ultimul an. Mulțumesc, nu aș fi putut scrie această carte fără tine.

Rick Schummer

Această carte este dedicată memoriei bunicului meu, Richard Holden. Bunicul mi-a dat o discuție motivațională în cea mai neagră zi a carierei mele la facultate. De fapt, mă gândeam să renunț la o diplomă în Informatică de la Universitatea Oakland. Acest om nu a terminat niciodată liceul, dar este unul dintre cei mai înțelepți oameni pe care i-am întâlnit în această viață. Dacă nu ar fi fost perspectiva lui, s-ar putea să nu fiu tociul computerelor care sunt astăzi. Pentru această direcție sunt veșnic recunoscător.
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Contractul nostru cu tine,

Cititorul

În care noi, cei care alcătuim Hentzenwerke Publishing, descriem la ce vă puteți aștepta, cititorul, de la această carte și de la noi.

Bună!

Am scris profesional (cu alte cuvinte, am primit în cele din urmă un salariu pentru mâzgălile mele) din 1974 și scriu despre dezvoltarea de software din 1992. Ca autor, am lucrat cu o jumătate de duzină de editori și am corespondat cu mii de cititori. de-a lungul anilor. În calitate de dezvoltator de software și tocitar, am achiziționat și o bibliotecă de peste o sută de cărți legate de computer și software.

Astfel, când am îmbrăcat șapca editorului în urmă cu patru ani pentru a produce Ghidul dezvoltatorului din 1997, am avut câteva idei destul de bune despre ceea ce mi-a plăcut (și nu mi-a plăcut) de la editori, ce mi-a plăcut și ce nu mi-a plăcut cititorilor și ce mi-a plăcut, ca cititor, i-a plăcut și nu i-a plăcut.

Acum, cu noile noastre titluri pentru primăvara și vara anului 2000, intrăm în al treilea sezon. (Pentru cei care țin evidența, DevGuide din 1997 a fost primul nostru sezon, deși prescurtat, iar lotul de șase „Esenziali” pentru Visual FoxPro 6.0 în 1999 a fost al doilea.)

John Wooden, renumitul antrenor de baschet UCLA, a postulat că echipele nu sunt consistente - devin mereu mai bune - sau mai rău. Ne-am dori să fim mai buni... Unul dintre obiectivele mele pentru acest sezon este să construiesc o relație mai strânsă cu tine, cititorul.

Pentru a face acest lucru, trebuie să știți la ce ar trebui să vă așteptați de la noi.

Aveți dreptul să vă așteptați ca comanda dumneavoastră să fie procesată rapid și corect și că cartea dumneavoastră vă va fi livrată în stare nouă.

Aveți dreptul să vă așteptați ca conținutul cărții dvs. să fie corect din punct de vedere tehnic, actualizat, că explicațiile sunt clare și că aspectul este ușor de citit și de urmat, fără multe puf sau prostii.

Aveți dreptul să vă așteptați la acces la codul sursă, errate, întrebări frecvente și alte informații care sunt relevante pentru carte prin intermediul site-ului nostru web.

Aveți dreptul să vă așteptați ca o versiune electronică a cărții dumneavoastră tipărite (în format HTML compilat de ajutor) să fie disponibilă prin intermediul site-ului nostru web.

Aveți dreptul să vă așteptați ca, dacă ne raportați erori, raportul dvs. va primi un răspuns prompt și că notificarea corespunzătoare va fi inclusă în errata și/sau Întrebări frecvente pentru carte.

Desigur, există anumite limite cu care ne confruntăm. Sunt oameni implicați și fac greșeli. O carte de 500 de pagini conține, în medie, 150.000 de cuvinte și câțiva megaocteți de cod sursă. Nu este posibil să editați și să reeditați de mai multe ori pentru a detecta ultimele greșeli de ortografie și de scriere, nici nu este posibil să testați codul sursă pe fiecare permutare a mediului de dezvoltare și a sistemului de operare - și totuși prețul cărții la preț accesibil.

Odată tipărite, legăturile se rup, cerneala este murdară, semnăturile sunt ratate în timpul legăturii. În ceea ce privește livrarea, site-urile web se prăbușesc, pachetele se pierd prin poștă.

Cu toate acestea, vom face tot posibilul pentru a corecta aceste probleme - după ce ne anunțați despre ele.

Și, astfel, în schimb, atunci când aveți o întrebare sau vă confruntați cu o problemă, vă rugăm să consultați mai întâi errata și/sau Întrebări frecvente pentru cartea dvs. de pe site-ul nostru. Dacă nu găsiți răspunsul acolo, vă rugăm să ne trimiteți un e-mail la books@hentzenwerke.com cu cât mai multe informații și detalii, inclusiv (1) pașii pentru a reproduce problema, (2) ce s-a întâmplat și (3) ce vă așteptați să faceți. se întâmplă, împreună cu (4) orice alte informații relevante.

Aș dori să subliniez că avem nevoie să comunicați întrebările și problemele în mod clar. De exemplu...

„Descărcările tale nu funcționează” nu sunt suficiente informații pentru ca noi să te ajutăm. „Primesc o eroare 404 când fac clic pe linkul Descărcare cod sursă de pe www.hentzenwerke.com/book/downloads.html.” este ceva cu care te putem ajuta.

„Codul din capitolul 14 a provocat o eroare” din nou nu este suficientă informație. „Am efectuat următorii pași pentru a rula programul de cod sursă DisplayTest.PRG din capitolul 14 și am primit o eroare care spunea „Variable m.liCounter” not found” este ceva cu care vă putem ajuta.

Vom face tot posibilul să vă răspundem în câteva zile fie cu un răspuns, fie cel puțin cu o confirmare că am primit întrebarea dvs. și că lucrăm la aceasta.

În numele autorilor, editorilor tehnici, editorilor de copie, artiștilor de layout, graficienilor, indexatorilor și tuturor celorlalți oameni care au lucrat pentru a pune această carte în mâinile dumneavoastră, aș dori să vă mulțumesc pentru achiziționarea acestei cărți și sper că se va dovedi a fi un plus valoros la biblioteca dumneavoastră tehnică. Vă rugăm să ne spuneți ce părere aveți despre această carte - așteptăm cu nerăbdare să auzim de la dvs.

După cum a observat odată Groucho Marx: „În afara unui câine, o carte este cel mai bun prieten al unui bărbat. În interiorul unui câine, este prea întuneric pentru a fi citit”.

În timp ce Hentzen

Editura Hentzenwerke

mai 2000
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Mulțumiri

Dacă ar fi să încercăm să recunoaștem, individual, pe toți cei care au contribuit, chiar și indirect, la această carte, am avea o listă de mulțumiri mai lungă decât cartea în sine. Dar există unele ale căror contribuții au fost atât de semnificative încât trebuie să le recunoaștem în mod specific.

În primul rând, am dori să recunoaștem editorul nostru tehnic, John Hosier. Fără John cartea nu ar fi fost niciodată într-o formă atât de bună. Nu numai că ne-a corectat atunci când am greșit, dar sugestiile și îmbunătățirile sale au fost de neprețuit pentru noi toți. Meseria de Editor tehnic este, în multe privințe, mai grea decât scrisul de fapt (și chiar mai ingrată), dar s-a descurcat minunat - mulțumesc mult, John.

Urmează, desigur, prietenul nostru și editorul galant, Whil Hentzen. El a fost inspirația din spatele acestei cărți (deși încă nu suntem siguri că ceea ce a primit a fost ceea ce și-a dorit inițial) și sprijinul și asistența sa au fost de neprețuit. Mulțumim, de asemenea, întregii echipe de la Hentzenwerke pentru că ne-au luat mâzgălirile aleatorii și au creat această carte minunată din ele. Apreciem cu adevărat.

Acum trebuie să abordăm cel mai dificil grup, comunitatea FoxPro. Ne considerăm foarte norocoși să fim membri, oricât de umili, ai acestei comunități minunate, multinaționale. Fără tine, această carte nu ar fi putut fi scrisă și cu siguranță nu s-ar fi vândut niciodată un singur exemplar.

Comunitatea FoxPro ESTE într-adevăr o comunitate și se susține fizic prin numeroasele grupuri de utilizatori bazate pe Fox din toate părțile lumii, electronic prin forumurile CompuServe, grupurile de știri, Universal Thread, FoxForum, Wiki și așa mai departe. Tovărășia și sprijinul reciproc sunt, credem noi, de neegalat și mult timp să rămână așa. A pune fețe numelor a făcut întotdeauna parte din distracția de a participa la DevCon, WhilFest, SoCal, Frankfurt, Amsterdam sau la oricare dintre multele alte conferințe și întâlniri FoxPro din întreaga lume. Că atât de multe dintre acele „fețe” au devenit, de asemenea, prieteni este un bonus minunat și așteptăm cu nerăbdare să reînnoim vechile prietenii și să construim altele noi în anii următori.

Deși este adevărat că toată lumea din comunitate a contribuit, într-un fel, la această carte, există câțiva indivizi ale căror contribuții au fost foarte directe și foarte specifice și vrem să profităm de această ocazie pentru a le mulțumi public.

· 	Steven Black (pentru utilitățile sale „Share” și „MC”)

· 	Gary DeWitt (pentru extragerea constantelor API-ului Windows)

· 	Tamar Granar și TedRoche (pentru indispensabilul „Ghid pentru hackeri pentru Visual FoxPro 6.0”)

· 	Doug Hennig (pentru că și-a împărtășit munca cu Visual FoxPro Builders)

· 	Christof Lange (pentru metoda sa de a face o aplicație FoxPro „instanță unică”)

· 	John Petersen (pentru contribuția sa la OptUtility)

Nu în ultimul rând, dar nu în ultimul rând, vine cea mai importantă persoană pentru noi, autorii, tu, Cititorul nostru. Vă mulțumim că ați cumpărat cartea. Sperăm să vă mulțumească și să vă fie de folos. Poate că, dacă suntem vreodată suficient de nebuni pentru a aborda un altul, îți vei aminti de noi și ne vei arunca o privire și atunci.

Andy Kramek Marcia Akins Rick Schummer

februarie 2000
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Despre noi

Andy Kramek

Andy este un consultant independent și dezvoltator FoxPro de lungă durată, cu sediul, la momentul scrierii, în Anglia. Pe lângă faptul că este cel mai valoros profesionist Microsoft, el este și un profesionist certificat Microsoft pentru Visual FoxPro atât în aplicațiile desktop, cât și în cele distribuite. Andy este un membru de mult timp al forumurilor de asistență FoxPro de pe CompuServe, unde este și SysOp.

Lucrarea publicată de Andy include „The Revolutionary Guide to Visual FoxPro OOP” (Wrox Press, 1996) și, împreună cu prietenul și colegul său Paul Maskens, coloana lunară „Kitbox” din FoxTalk (Pinnacle Publications). Andy a vorbit la conferințe și întâlniri ale grupurilor de utilizatori în Anglia, Europa continentală și SUA.

În puținul timp liber pe care îl are, lui Andy îi place să joace squash și golf (deși nu neapărat în același timp), să călătorească și să o asculte pe Marcia.

Îl poți contacta pe Andy la:

Marcia Akins

Marcia este un dezvoltator cu experiență în mai multe limbi, care a lucrat în principal în Visual FoxPro în ultimii opt ani. Ea este consultantă independentă și, la momentul scrierii, părăsise Ohio-ul natal pentru a trăi și a lucra (cu Andy) timp de aproximativ un an în Anglia. Ea este cea mai valoroasă profesionistă Microsoft și deține calificări Microsoft Certified Professional atât pentru Visual FoxPro Desktop, cât și pentru aplicațiile distribuite.

Ea are mai multe articole în FoxPro Advisor la creditul ei și este cunoscută pe scară largă, și cel puțin pe jumătate în serios, drept „Regina „o” grilelor”. Ea a vorbit la conferințe și întâlniri ale grupurilor de utilizatori din SUA, Anglia și Europa continentală și contribuie frecvent la CompuServe, Universal Thread și FoxForum.com.

Când nu este ocupată să dezvolte software, Marcia îi place să joace golf, să schieze, să joace tenis, să se antreneze la sală, să călătorească și să-l hărțuiască pe Andy.

Puteți ajunge la Marcia la:

MarciaGAkins@Compuserve.com

Rick Schummer

Rick este directorul de dezvoltare pentru Kirtland Associates, Ine. în Troy MI, SUA. Kirtland Associates scrie aplicații de baze de date personalizate pentru o bază de clienți care se extinde rapid. El nu numai că conduce dezvoltarea acestei organizații distractive, dar participă și la educarea dezvoltatorilor Visual FoxPro noi și experimentați. Este o modalitate excelentă de a-ți dezvolta propriile abilități. După ore, îi place să scrie instrumente pentru dezvoltatori care îmbunătățesc productivitatea echipei sale și ocazional scrie articole pentru FoxTalk, FoxPro Advisor și mai multe buletine informative ale grupului de utilizatori.

Rick a devenit recent Microsoft Certified Professional prin promovarea examenelor VFP Desktop și Distributed.

Își petrece timpul liber cu familia, îi înveselește pe copii în timp ce joacă fotbal, are un rol voluntar cu Boy Scouts și îi place să petreacă timpul în camping, ciclism, strângerea de monede, fotografierea și lectura. Rick este membru fondator și secretar atât al Detroit Area Fox User Group (DAFUG - http://www.dafug.org) cât și al Sterling Heights Computer Club (http://member.apcug.org/shcc).

Puteți contacta Rick la:

rschiimmer@compuserve. porumb

raspi/kirtlandsys. сот http://ту. voyager, net/rschiimmer

John Hosier

John este activ în comunitatea FoxPro din 1987 și a fost dezvoltator, consultant, autor, speaker și trainer. John a fost, de asemenea, membru fondator al consiliului de administrație al Mid-Atlantic FoxPro User Group și a fost președinte și trezorier al acestuia. Ca consultant, John a lucrat atât cu clienți mari, cât și cu mici din Europa de Est și de Vest, Orientul Mijlociu, Caraibe și peste tot în Statele Unite. Creditele de publicare ale lui John includ FoxPro Advisor, FoxTalk, FoxPro User's Journal și o revistă germană numită „Data Base: Das Fachmagazin fur Datenbankentwickler”. Nu, John nu vorbește germană, dar crede că este destul de amuzant că a scris un articol pe care nu l-a putut citi în publicația finală. În calitate de profesionist certificat Microsoft în Visual FoxPro, John a lucrat la o mare varietate de proiecte, inclusiv client server, intemet/intranet (inclusiv un parser XML scris în VFP) și aplicații distribuite. În prezent, John își face casa în zona Chicago.

Îl poți contacta pe John la:
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Cum să descărcați fișierele

Există două seturi de fișiere care însoțesc această carte. Primul este codul sursă referit în tot textul și notat de pictograma pânză de păianjen; a doua este versiunea de carte electronică a acestei cărți - fișierul HTML Help (.CHM) compilat. Iată cum să le obțineți.

Atât codul sursă, cât și fișierul CHM sunt disponibile pentru descărcare de pe site-ul web Hentzenwerke. Pentru a face acest lucru, urmați aceste instrucțiuni:

1. 	Îndreptați browserul dvs. web către www.hentzenwerke.com.

2. 	Căutați linkul care spune „Descărcați codul sursă și fișierele .CHM”. (Textul pentru acest link se poate modifica în timp - dacă se întâmplă, căutați un link care să facă referire la Cărți sau Descărcări.)

3. 	Va apărea o pagină care descrie procesul de descărcare. Această pagină are două secțiuni.

Secțiunea 1: Dacă ați primit un nume de utilizator/parolă de la Hentzenwerke Publishing, le puteți introduce în această pagină.

Secțiunea 2: Dacă nu ați primit un nume de utilizator/parolă de la Hentzenwerke Publishing, nu vă faceți griji! Doar introduceți aliasul dvs. de e-mail și căutați întrebarea despre cartea dvs. Rețineți că veți avea nevoie de carte când răspundeți la întrebare.

4. 	Va apărea o pagină care listează hyperlinkurile pentru descărcările corespunzătoare.

Rețineți că fișierul .CHM este acoperit de aceleași legi privind drepturile de autor ca și cartea tipărită. Reproducerea și/sau distribuirea fișierului .CHM este împotriva legii.

Dacă aveți întrebări sau probleme, cel mai rapid mod de a obține un răspuns este să ne trimiteți un e-mail la books@hentzenwerke.com.
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Capitolul 1 - Controlul mediului VFP

„Pentru a începe de la început” (Narator, „Under Milk Wood” de Dylan Thomas)

Unul dintre avantajele majore ale dezvoltării în Visual FoxPro este că aveți control aproape complet asupra mediului în care va rula codul. Cu toate acestea, la fel ca multe beneficii, aceasta poate fi o sabie cu două tăișuri și există multe lucruri de care trebuie să fii conștient atunci când stabiliți și controlați atât mediile de dezvoltare, cât și de producție. În acest capitol vom acoperi câteva dintre tehnicile pe care le-am găsit că funcționează bine.
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Pornirea Visual FoxPro

Visual FoxPro, ca majoritatea aplicațiilor, acceptă mai multe „comutatoare ale liniei de comandă”. De cele mai multe ori acestea tind să fie uitate, dar ele există și sunt toate documentate în fișierele de ajutor online din subiectul „Personalizarea opțiunilor de pornire Visual FoxPro”. Probabil cele mai utile de reținut sunt:

· 	-C care specifică fișierul de configurare de utilizat

· 	-T care suprimă ecranul de conectare VFP

· 	-R care reîmprospătează setările de registry VFP (Notă, setările care se reîmprospătează sunt cele referitoare la informații despre VFP, cum ar fi asocierile de fișiere. Comutatorul -R nu actualizează setările controlate prin dialogul Opțiuni Visual FoxPro. Acest lucru se face doar când se folosește „Set As Default” pentru a ieși din dialog).

Deci, pentru a porni Visual FoxPro fără afișarea ecranului de conectare și cu o reîmprospătare a setărilor de registry, linia de comandă necesară ar fi:

G:\VFP60\VFP6.EXE —R -T
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Fișiere de configurare

Există mai multe moduri de a gestiona inițializarea Visual FoxPro, dar cea mai ușoară și mai flexibilă este totuși utilizarea unui fișier de configurare. Visual FoxPro folosește un fișier text format simplu, numit „CONFIG.FPW” în mod implicit, ca sursă pentru un număr de valori de mediu care pot fi setate la pornirea sistemului.

Cum se specifică un fișier config.fpw

Numele actual al fișierului nu contează, deoarece puteți specifica fișierul de configurare pe care Visual FoxPro îl va folosi ca parametru de linie de comandă folosind comutatorul „-c” din linia de comandă care este utilizată pentru a porni Visual FoxPro. Deci, pentru a configura propriul fișier de configurare (de exemplu pentru o anumită aplicație), utilizați următoarea linie de comandă:

G:\VFP60\APPS\MYAPP.EXE -cG:\VFP60\myconfig.txt

Cum își localizează VFP fișierul de configurare

Comportamentul implicit al Visual FoxPro, în absența unui fișier de configurare specific, este să caute în următoarele locații un fișier numit „config.fpw” în această ordine:

· 	Directorul de lucru curent

· 	Directorul din care este pornit Visual FoxPro

· 	Toate directoarele din calea DOS

Dacă utilizați comutatorul „-c” pentru a specifica un fișier cu alt nume decât cel implicit sau într-o locație specifică, trebuie să includeți calea complet calificată și numele fișierului. Aceasta oferă o metodă simplă de gestionare a inițializării diferitelor aplicații instalate pe aceeași mașină.

Cum pornește VFP când nu este găsit niciun fișier de configurare

Dacă nu este găsit sau specificat niciun fișier de configurare, atunci Visual FoxPro va fi pornit doar cu acele setări care sunt specificate în Dialogul Opțiuni (situat în panoul TOOLS din meniul principal Visual FoxPro).

De ce aceste setări în special?

Răspunsul este pur și simplu că toate setările din acest dialog sunt de fapt stocate în Registrul Windows și pot fi găsite sub cheia de registru:

HKEY_CURRENT_USER\Software\Microsoft\VisualFoxPro\6.0\Options

Includerea unui fișier de configurare în proiect

O mică „capcană” la care trebuie să aveți grijă - dacă adăugați un fișier de configurare numit „config.fpw” la proiect ca fișier text, acesta va fi INCLUS în proiect în mod implicit. Când construiți un .exe din proiect, fișierul config.fpw va fi încorporat în fișierul rezultat. Deoarece Visual FoxPro caută un fișier numit „config.fpw” în timpul pornirii, va găsi întotdeauna mai întâi versiunea încorporată și nu va căuta mai departe. Acest lucru s-ar aplica chiar dacă ar trebui să specificați în mod explicit un fișier de configurare diferit folosind comutatorul „-C”! Fișierul specificat va fi ignorat și fișierul de configurare încorporat va fi executat. Cea mai bună soluție este să NU adăugați deloc fișierul de configurare la proiect, dar dacă o faceți, să vă asigurați că este marcat ca „exclus” din build.

Cum să suprimați un fișier de configurare

Pornirea Visual FoxPro numai cu parametrul de linie de comandă „-c” suprimă comportamentul implicit și împiedică rularea oricărui fișier de configurare care poate fi găsit. Rezultatul este că puteți forța Visual FoxPro să pornească numai cu setările implicite.

Cum să determinați ce fișier de configurare este utilizat

Una dintre cele mai frecvente probleme cu fișierele de configurare este că nu se asigură că Visual FoxPro citește corect CONFIG.FPW. După cum sa menționat mai sus, dacă Visual FoxPro nu poate găsi un fișier de configurare, va căuta calea DOS și va folosi pur și simplu prima pe care o găsește. Acest lucru ar putea fi oriunde într-o rețea. Funcția SYS (2019) va returna calea completă și numele fișierului de configurare pe care Visual FoxPro l-a folosit de fapt. Dacă nu a fost găsit niciun fișier de configurare, funcția returnează doar un șir gol.
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Ce intră în fișierul de configurare?

Acum că știm ceva despre cum este utilizat fișierul de configurare, următoarea întrebare este ce putem pune în el? Răspunsul este destul de mult! În esență, există trei categorii de lucruri care pot fi specificate în fișierul de configurare, după cum urmează:

Setări speciale

Există o serie de setări care pot fi făcute NUMAI într-un fișier de configurare. (Pentru detalii complete, consultați subiectul „Termeni speciali pentru fișierele de configurare” din Ajutorul online Visual FoxPro și intrarea din „Configurarea Visual FoxPro” din documentația online.) Observați că posibilitatea de a seta locația fișierelor temporare este disponibilă și în dialogul Opțiuni. Specificarea locației TMPFILES în fișierul de configurare va suprascrie orice setare care este făcută acolo și poate fi utilă atunci când trebuie să faceți diferența între locațiile de dezvoltare și de rulare pentru fișierele temporare.

Tabelul 1.1 Exemplu de termeni specifici pentru fișierul de configurare

Descrierea cuvântului cheie	
MVCOUNT = nn 	Setează numărul maxim de variabile pe care Visual FoxPro le poate menține. Această valoare poate varia de la 128 la 65.000; implicit este 1024.
TMPFILES = drive: 	Specifică unde sunt stocate fișierele de lucru temporare EDITWORK, SORTWORK și PROGWORK dacă nu au fost specificate cu nici una dintre celelalte opțiuni. Deoarece fișierele de lucru pot deveni foarte mari, specificați o locație cu mult spațiu liber. Pentru o performanță mai rapidă, în special într-un mediu multiutilizator, specificați un disc rapid (cum ar fi un disc local). Implicit este directorul de pornire.
OUTSHOW = OFF 	Dezactivează capacitatea de a ascunde toate ferestrele în fața ieșirii curente apăsând SHIFT+CTRL+ALT. Implicit este ON.

O altă setare care poate fi utilizată numai în fișierul de configurare, dar care nu este inclusă în lista de fișiere de ajutor este „ECRAN = OFF”. Acest lucru împiedică afișarea ecranului principal Visual FoxPro la pornirea aplicației și previne „flash” enervant al ecranului VFP care apare chiar dacă programul de pornire oprește ecranul principal cu comanda _screen.visibie = . F. (care vă permite să prezentați formularul inițial al aplicației sau un ecran „splash”, fără a afișa mai întâi fereastra principală VFP).

SET comenzi

Practic, toate comenzile standard SET pot fi emise într-un fișier de configurare. Singurul lucru la care trebuie să aveți grijă este că unele setări sunt de fapt vizate de sesiunea de date. (Consultați subiectul „Setare DataSession” din Ajutorul online pentru o listă completă.) Deci, nu are rost să le specificați în fișierul de configurare dacă intenționați să utilizați Private DataSessions pentru formularele dumneavoastră. Sintaxa pentru specificarea comenzilor SET în fișierul de configurare este o atribuire simplă în care cuvântul cheie „SET” este omis:

IMPLICIT = C:\VFP60\TIPSBOOK

DATA = BRITANICA

Comenzi

Ei bine, de fapt, puteți specifica doar o singură comandă (numărați-le!) și trebuie să fie ultima linie a fișierului de configurare. Ca și alte intrări ale fișierului de configurare, acesta este introdus ca o simplă atribuire:

COMANDĂ = DO setupfox

La ce folosește o singură comandă? Ei bine, destul de multe pentru că acea comandă poate cali un program FoxPro și asta poate face o mulțime de lucruri!

Una dintre principalele limitări ale fișierului de configurare este că nu puteți seta de fapt lucrurile care sunt interne Visual FoxPro (de exemplu, variabilele de sistem), deoarece, atunci când fișierul de configurare rulează, Visual FoxPro nu a pornit de fapt. Utilizarea acestei setări vă permite să specificați un fișier de program pentru a rula imediat după ce Visual FoxPro a pornit - chiar înainte ca fereastra de comandă să fie afișată.

Acest program poate fi apoi folosit pentru a configura mediul de dezvoltare așa cum doriți cu adevărat. De exemplu, iată câteva dintre lucrurile care se află în fișierul nostru de configurare standard:

*** Opțiuni standard „SET” (Acestea pot fi introduse direct în fișierul de configurare) SET TALK OFF

OPRIȚI SLOPERUL

OPRITĂ SIGURANȚA

SETARE STARE OFF

ACTIVATĂ BARA DE STARE

SETARE DATA BRITISH

PUNEȚI SECOLUL

*** Redefiniți tastele funcționale

SETĂ FUNCȚIA 2 LA „ÎNCHIDERE TOATE TABELE; ȘTERGE FERESTELE;”

SETĂ FUNCȚIA 3 LA „CANCEL;SET SYSMENU TO DEFA;ACTIVATE WINDOW COMMAND;”

SETĂ FUNCȚIA 4 LA „ȘTERGE TOTUL;SETARE CLASLIB LA;SETARE PROC LA;”

SETĂ FUNCȚIA 5 LA „DISP STRU;”

SETĂ FUNCȚIA 6 LA „DISP STAT;”

SETĂ FUNCȚIA 7 LA „AFIȘARE MEMO LIKE *”

SETĂ FUNCȚIA 8 LA „ȘTERGE;ȘTERGEȚI FERESTELE;”

SETĂ FUNCȚIA 9 LA „FORMUL MODI”

SETĂ FUNCȚIA 10 LA „MODI COMM”

SETĂ FUNCȚIA 11 LA „FACEȚI calea setării CU”

SETĂ FUNCȚIA 12 LA „=CHGDEFA(); ”

***Configurați proprietățile ecranului

_SCREEN.CAPTION = „VFP 6.0 (Mod de dezvoltare)”

_ECRAN.ÎNCHIS = .F.

_SCREEN.FONTNAME = „Arial”

_SCREEN.FONTSIZE = 10

_SCREEN.FONTBOLD = .F.

*** Rulați Cobb Editor Extensions

DO G:\VFP60\CEE6\CEE6.APP

*** Configurați câteva etichete On Key

ON KEY LABEL CTRL+F10 suspend

PE Eticheta tastei CTRL+F11 o=SYS(1270)

PE Eticheta tastei CTRL+F12 ELIBERARE o

*** Configurați orice variabile de sistem necesare

_Include = HOME() + „Foxpro.h”

_Accelerație = 0,1

*** Configurați orice variabile standard „publice”.

PUBLIC gcUserName, gcAppPath, gcDataPath

STOCAZĂ „” ÎN gcUserName, gcAppPath, gcDataPath

*** Rulați Configurarea căii standard

Efectuați setpath CU 1

După cum puteți vedea, pe lângă configurarea mediului de bază al sistemului VFP și gestionarea propriilor cerințe speciale, această comandă „una” disponibilă în fișierul de configurare a fost acum folosită pentru a rula alte câteva programe (CEE și propria noastră procedură SetPath) deci primim trei la prețul unuia. Prin introducerea acestor setări într-un program, avem și o modalitate simplă de a reinițializa mediul prin re-rularea acestui program în orice moment.
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Dându-i o cale VFP

Visual FoxPro are capacitatea de a utiliza propria cale de căutare și, ca regulă generală, ar trebui să specificați întotdeauna o cale pentru Visual FoxPro atât pentru mediile de dezvoltare, cât și pentru mediile de producție - deși acestea pot fi foarte diferite (vezi mai sus pentru o modalitate de a gestiona această cerință ). Setarea unei căi pentru Visual FoxPro nu schimbă calea normală de căutare DOS, dar poate accelera semnificativ aplicația dvs. prin limitarea locurilor pe care Visual FoxPro trebuie să le caute pentru a-și găsi fișierele - în special într-un mediu de rețea.

Cum caută fișierele VFP

În mod implicit, Visual FoxPro utilizează directorul curent ca „cale” și puteți oricând să restabiliți această setare prin simpla emisiune: SET PATH TO

Cu toate acestea, pentru aplicații mai sofisticate și în dezvoltare, veți avea în mod normal un fel de structură de directoare și ar trebui să setați întotdeauna o cale de căutare adecvată pentru a include toate directoarele necesare.

Setarea directorului implicit

În mod normal, veți dori totuși să setați un director implicit (sau „de lucru”) - aici este locul în care Visual FoxPro va căuta mai întâi orice fișier de care are nevoie. Acest lucru se poate face în mai multe moduri, în funcție de cerințele dvs.:

• 	Specificați o valoare implicită în fișierul de configurare folosind DEFAULT = <calea către director>

• 	Setați valoarea implicită direct în cod folosind SET DEFAULT TO <calea către director>

• 	Schimbați într-un director folosind CD-ul <calea către director> și emiteți SET PATH TO

Rețineți că utilizarea funcțiilor Get, Put sau Locate (de exemplu GetDir()) nu schimbă nici directorul implicit, nici calea. Pentru a schimba directorul implicit, utilizați interactiv: SET DEFAULT TO ( GetDir() ). (Comanda „cd” (sau „chdir”) poate fi folosită și pentru a schimba atât unitatea, cât și directorul în locația specificată).

Folosind comanda SET PATH

Stabilirea căii este simplitatea în sine. Emiteți comanda SET PATH urmată de o listă a directoarelor pe care doriți să le includeți. Nu trebuie să calificați complet subdirectoarele - este suficient să le separați fie prin virgule, fie prin punct și virgulă. Exemplul arată o cale de căutare tipică Visual FoxPro:

SETARE CALEA LA G:\VFP60;C:\VFP60\TIPSBOOK\;DATE;FORMS;LIBS;PROG;UTILS;

Pentru a prelua setarea curentă a căii, puteți utiliza funcția SET() (care va funcționa cu majoritatea comenzilor Visual FoxPro SET), așa cum se arată mai jos. Puteți atribui rezultatul direct unei variabile sau, așa cum se arată mai jos, direct în clipboard, astfel încât apoi să puteți lipi calea curentă într-un program sau într-un fișier de documentație:

ClipText = SET('CALEA')

Visual FoxPro permite utilizarea ambelor nume de căi UNC, cum ar fi:

\\SERVERNAME\DIRECTORYNAME\.

și permite utilizarea spațiilor încorporate (atunci când sunt incluse între ghilimele) în nume de director cum ar fi:

„..\DIRECTOR COMUN\”

Cu toate acestea, deși acestea din urmă pot fi permise, avem tendința de a subscrie la principiul că „deși puteți utiliza spații încorporate, arsenicul este mai rapid” (Același lucru, apropo, se aplică numelor de fișiere cu spații!) În timp ce îmbunătățim lizibilitatea, spațiile poate cauza, de asemenea, probleme atunci când încercați să gestionați fișierele și directoarele în mod programatic și încă credem că cel mai bun sfat este să le evitați oriunde este posibil în aplicații. De exemplu, următorul cod funcționează perfect pentru numele de directoare convenționale, dar va eșua dacă directorul selectat conține spații încorporate:

LOCAL lcDir

lcDir = GETDIR()

DACĂ ! EMPTY(lcDir)

SETARE IMPLICIT LA &lcDir

ENDIF

Unde sunt?

Din fericire, Visual FoxPro ne oferă o serie de funcții care ne vor ajuta să găsim unde ne aflăm în orice moment:

• 	SYS(2004) returnează directorul din care a fost pornit Visual FoxPro, dar într-o aplicație de rulare distribuită, aceasta va fi întotdeauna locația VFP6R.DLL (care este în mod normal versiunea corespunzătoare a directorului „Sistem” Windows)

• 	home() returnează directorul din care a fost pornit Visual FoxPro în mod implicit, dar are o serie de opțiuni suplimentare utile în VFP6 care returnează informații despre componentele Visual Studio

• 	_vfp.fullname accesează o proprietate a obiectului aplicației Visual FoxPro care conține calea completă și numele fișierului care a fost folosit pentru a porni VFP

• 	fullpath(' ' ) sau fullpath( curdir() ) returnează unitatea completă și directorul directorului de lucru curent (inclusiv terminalul „\”).

• 	sys(5) returnează unitatea implicită (inclusiv „:”)

• 	CD-ul arată unitatea și directorul curent în fereastra de ieșire curentă - dar va schimba și unitatea și directorul într-o singură comandă

• 	CHDiR se va schimba în Drive/Driectory specificat (la fel ca cd-ul), dar nu va raporta starea curentă (și astfel nu vă încurcă formularele)

• 	curdir() returnează doar directorul curent (cu terminalul '\'), dar nu şi unitatea

Cum să setați o cale în mod programatic

Ca o alternativă la codificarea tare a căilor din fișierul de configurare, este posibil să derivați calea (presupunând că utilizați structuri de directoare standard) folosind funcțiile native Visual FoxPro. Mica funcție de mai jos arată cum s-ar putea face acest lucru pentru a lua în considerare atât structurile de dezvoltare, cât și cele de rulare. Folosește funcția programo pentru a determina cum a fost apelată și returnează o cale diferită atunci când este apelată dintr-un formular sau dintr-un program decât atunci când este apelată dintr-un fișier compilat:

**************************************************** ****************************

* 	Program. CalcPath.prg

* 	Versiunea....: 1.0

* 	Autor....: Andy Kramek

* 	Data......: 16 august 1999

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Setează o cale VFP pe baza tipului programului apelant.

* 	..........:Presupune structuri standard de directoare - dar ar putea folosi căutări

**************************************************** ****************************

FUNCȚIE CalcPath()

LOCAL lcSys16, lcProgram, lcPath, lcOldDir

*** Obțineți numele programului care l-a numit pe acesta.

lcSys16 = SYS(16, 1)

*** Salvați directorul de lucru curent

lcOldDir = (SYS(5)+CURDIR())

*** Faceți actual directorul din care a fost rulat

lcProgram = SUBSTR(lcSys16, AT(":", lcSys16) - 1)

CD LEFT(lcProgram, RAT("\", lcProgram))

IF INLIST( JUSTEXT(lcProgram ), „FXP”, „SCX” )

*** Dacă rulăm direct un PRG/Form, atunci găsim directorul părinte

CD ..

*** Configurați calea pentru a include VFP Home plus arborele standard de directoare DEV

lcPath = (HOME()+';'+SYS(5)+CURDIR()+";DATE;FORMS;LIBS;PROG;UTILS")

ALTE

*** Folosim un EXE/APP! Ajustați calea pentru arborele de directoare DISTRIBUTION

lcPath = (HOME()+';'+SYS(5)+CURDIR()+";DATE")

ENDIF

*** Restaurați directorul original

CD (lcOldDir)

*** Întoarce calea calculată

RETURN lcPath

ENDFUNC
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Asigurați-vă că VFP este pornit o singură dată

Până acum, bine! Am reușit să acoperim procesul de pornire a VFP și crearea mediilor de bază atât pentru dezvoltare, cât și pentru producție. În acest moment, unul dintre lucrurile pe care le întâlnim cu toții este utilizatorul absent care minimizează o aplicație și apoi, zece minute mai târziu, începe o copie nouă de pe desktopul său. În decurs de o oră, au șase copii ale aplicației care rulează și se plâng că mașina lor încetinește. Ce să fac? (Pe lângă împușcarea utilizatorului care, oricât de atrăgătoare ar fi ideea, este în general respinsă și, în funcție de vechimea lor, poate fi și o mișcare care limitează cariera.) Există de fapt mai multe abordări care pot fi luate, așa cum este descris mai jos.

Folosind un fișier „sémafor”.

Aceasta este probabil cea mai simplă abordare dintre toate. Se bazează pe aplicația dvs. care creează, la prima lansare, un fișier de zero octeți al cărui singur scop este să indice că aplicația rulează. De fiecare dată când aplicația este lansată, caută acest fișier și, dacă îl găsește, pur și simplu se închide din nou:

**************************************************** ****************************

* 	Program. ChkSFile.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Verifică un fișier Sémaphore, creează unul dacă nu este găsit și

* 	..........:returnează un steag

**************************************************** ****************************

FONCTION ChkSFile(tcAppName)

LOCAL lcAppName, lcFile, lnHnd, llRetVal

*** LcAppName implicit dacă nu a trecut nimic

lcAppName = IIF( EMPTY(tcAppName) SAU VARTYPE(tcAppName ) # "C", ;

' apprun ' , LOWER ( ALLTRIM ( tcAppName ) ) )

*** Forțați o extensie TXT pentru fișierul semafor din directorul curent

lcFile = (SYS(5) + CORDIR() + FORCEEXT(lcAppName, 'txt' ))

*** Acum verificați fișierul?

DACĂ ! FILE( lcFile )

*** Fișierul nu a fost găsit, așa că creați-l

lnHnd = FCREATE( lcFile )

DACA lnHnd < 0

*** Nu se poate crea fișierul, un fel de eroare! Setați indicatorul de returnare llRetVal = .T.

ALTE

*** Închideți fișierul

FCLOSE( lnHnd )

ENDIF

ALTE

*** Setați steagul de întoarcere

llRetVal = .T.

ENDIF

*** Întoarce steagul de stare

RETURN llRetVal

Funcția returnează o valoare logică care poate fi utilizată pentru a determina dacă se permite continuarea aplicației curente, așa cum ilustrează următorul fragment:

*** Verificați o a doua instanță a aplicației

IF ChkSFile()

PĂRĂSI

ENDIF

Desigur, problema cu această abordare este că aplicația dvs. trebuie să ștergă fișierul ca parte a rutinei sale de închidere (cu excepția cazului în care doriți cu adevărat o aplicație o singură dată). Asta ridică întrebarea ce poți face dacă, cerul ferește, aplicația se termină anormal (eufemism pentru „crash”) sau utilizatorul face o ieșire necorespunzătoare (deconectarea sursei de alimentare de exemplu!). Răspunsul este „Nu mult”. De obicei, acest lucru va necesita intervenția „System Support” pentru a șterge fizic fișierul.

Dar este o abordare plăcută, ușoară, fără alte dezavantaje reale, cu condiția ca fișierul semafor să fie întotdeauna creat pe mașina utilizatorului final sau într-un anumit director de utilizator.

Folosind API-ul Windows

Funcția de mai jos folosește trei funcții API Windows pentru a căuta o fereastră care poartă numele aplicației (FindWindow), pentru a transforma o fereastră existentă în fereastra cea mai sus (BringWindowToTop) și pentru a o maximiza (ShowWindow):

**************************************************** ****************************

* 	Program. OnceOnly.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Verifică pentru o instanță existentă a ferestrei aplicației

* 	..........:și, dacă este găsit, activează originalul și returnează un steag.

**************************************************** ****************************

FUNCȚIE O singură dată

LOCAL lnHWND, lcTitle, llRetVal

*** Configurați apeluri API

Declarați Integer FindWindow ÎN Win32Api AS FindApp String, String

Declarați BringWindowToTop ÎN Win32APi AS MakeTop Integer

Declarați ShowWindow ÎN Win32Api AS ShowWin Integer, Integer

*** Obțineți subtitrarea actuală a ecranului

lcTitle = _Screen.Caption

*** Schimbați-l pentru a evita găsirea instanței curente

_Screen.Caption = SYS(3)

*** Acum găsiți o altă instanță

lnHWND = FindApp( NULL, lcTitle )

*** Și restabiliți legenda originală

_Screen.Caption = lcTitle

*** Verificați rezultatele

DACĂ lnHWND > 0

*** Am găsit ceva!

*** Deci, pune-l pe partea de sus și maximizează-l (ShowWin => 3)

MakeTop( lnHWND )

ShowWin( lnHWND, 3 )

*** Setați valoarea de returnare

llRetVal = .T.

ENDIF

*** Returnați starea pentru acțiune

RETURN llRetVal

Funcția returnează o valoare logică care poate fi utilizată pentru a determina dacă se permite continuarea aplicației curente, așa cum ilustrează următorul fragment:

*** Verificați o a doua instanță a aplicației

DACA O singura data()

PĂRĂSI

ENDIF

Există un dezavantaj major la care trebuie să fiți atenți aici. Funcțiile API utilizate verifică numele unei ferestre - în acest caz folosim Screen.Caption. Dacă aplicația dvs. modifică subtitrarea ecranului în timpul rulării (la fel ca mulți), această abordare nu va funcționa.

Combinație de semafor și API Windows

Ultimul exemplu de aici arată cum combinarea principiilor celorlalte două exemple oferă o abordare generală mai bună:

**************************************************** ****************************

* 	Program. ...: IsAppRun.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Verifică o fereastră care este creată cu un ID unic de și

* 	...........: în cerere. Combinație de Semafor și API.

* 	...........: Pe baza codului postat inițial în Domeniul Public

* 	..........:de Christof Lange

**************************************************** ****************************

FUNCȚIA IsAppRun(tcUniqueID)

LOCAL llRetVal, lcUniqueID

*** TREBUIE să treacă un ID de aplicație acestei funcții!

IF EMPTY(tcUniqueID) SAU VARTYPE(tcUniqueID) # "C"

MESSAGEBOX( „Un ID de caracter specific aplicației este obligatoriu” + CHR.(13) ;

+ „când se apelează funcția IsAppRun()”, 16, „Eroare dezvoltator” )

RETURNARE .T.

ALTE

*** Eliminați orice spațiu

lcUniqueID = STRTRAN( tcUniqueID, " " )

ENDIF

*** Verificați mai întâi existența ferestrei Semafor

IF WEXIST("_Semafor_")

RETURNARE .T.

ENDIF

*** Căutați o apariție a acestui ID ca nume de fereastră

DECLARE INTEGER FindWindow IN Win32Api AS FindApp String, String

DACĂ FindApp( NULL, lcUniqueID ) > 0

*** Am găsit unul! Setați valoarea de returnare

llRetVal = .T.

ALTE

*** Creați o nouă fereastră cu acest ID

DEFINIȚI FEREASTRA _Semafor_ ÎN DESKTOP DE LA 1,1 LA 2,2 TITLUL lcUniqueID

ENDIF

*** Întoarce steagul de stare

RETURN llRetVal

Pentru a utiliza această funcție, este cel mai simplu să includeți un #DEFINE în fișierul de pornire standard, astfel încât să puteți specifica un nou ID unic pentru fiecare aplicație:

#DEFINE APPID „App0001-99”

IF IsAppRun( APPID )

PĂRĂSI

ENDIF

Această soluție foarte îngrijită evită atât problema „fișierelor atârnate” în metoda semaforului, cât și cea a modificării legendei în metoda API, deoarece fereastra poate fi creată și menținută doar într-o instanță a aplicației. De îndată ce se termină în orice fel - chiar și ca urmare a unui accident - fereastra este distrusă și nu există nimic de curățat. Deoarece fereastra își primește numele în mod explicit din aplicație, nici nu se bazează pe faptul că legenda este constantă. Lucruri grozave Christof, mulțumesc!
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SET Comenzi și DataSessions

OK - avem Visual FoxPro în funcțiune (și ne-am asigurat că putem porni o singură instanță a aplicației noastre) și acum ce? Există, în cazul în care nu ați observat, o mulțime de comenzi SET în Visual FoxPro care vă permit să configurați mediul în detaliu. Multe dintre acestea afectează mediul la nivel global, dar unele sunt incluse în sesiunea de date activă în prezent (consultați subiectul „Set DataSession” din ajutorul on-line pentru o listă completă a acestora). Când porniți Visual FoxPro, vă aflați întotdeauna în sesiunea de date DEFAULT.

Ce înseamnă exact „Sesiune de date implicită”?

Dicționarul englez Oxford (ediția a noua) oferă o definiție a „implicit” ca:

„O opțiune preselectată adoptată de un program de calculator atunci când nu este specificată nicio alternativă de către utilizator sau programator”

Din păcate, Visual FoxPro pare să prefere să definească cuvântul conform regulilor oferite de Humpty-Dumpty în „Alice Through the Looking Glass” de Lewis Carroll:

„Când folosesc un cuvânt”, a spus Humpty Dumpty pe un ton mai degrabă disprețuitor, „înseamnă exact ceea ce aleg eu să spună – nici mai mult, nici mai puțin”.

De fapt, DataSession implicită este de fapt DataSession #1 - nici mai mult, nici mai puțin. Nu are nicio semnificație specială în afară de faptul că atunci când porniți Visual FoxPro, acesta este selectat (la fel cum Zona de lucru #1 este întotdeauna selectată ca prima zonă de lucru disponibilă în orice DataSession). Acest lucru este ușor de demonstrat folosind fereastra SET DATASESSION și fereastra de comandă.

Când deschideți fereastra DataSession, va afișa numele sesiunii de date curente ca „Default(1)”, însă comanda:

SETATI SESIUNEA DE DATE LA IMPACT

are ca rezultat o eroare Variable Default Not Found, while

SETĂ SESIUNEA DE DATE LA 1

este acceptat fără comentarii.

Cu toate acestea, atunci când rulați un formular a cărui proprietate DataSession este setată la „1 sesiune de date implicită”, VFP interpretează termenul „implicit” ca însemnând „CURRENT” - cu alte cuvinte, un formular care este conceput folosind această setare va folosi oricare sesiune de date. este activ când formularul este inițializat. Acest lucru nu pare foarte logic la prima vedere, deoarece ne-am putea aștepta în mod rezonabil că, deoarece Sesiunea de date #1 este numită „Implicit”, setarea proprietății DataSession a unui formular la „1 Sesiune de date implicită” ar asigura că formularul va folosi efectiv acea sesiune de date și nici alta. Nu asa!

Comportamentul real are sens atunci când doriți ca formularele să partajeze o sesiune de date. Setând proprietatea DataSession a formularului copil la 1 (Sesiune de date implicită), acesta va folosi orice sesiune de date folosită de formularul său părinte - indiferent dacă acea sesiune de date este privată sau nu.

Deci, pot avea o sesiune de date „publică”?

Răspunsul scurt este NU! Visual FoxPro acceptă conceptul unei sesiuni de date cu adevărat „implicite” (sau „publice”). Cu alte cuvinte, dacă un tabel specificat nu este găsit în sesiunea de date curentă, VFP nu îl va căuta în altă parte. Toate sesiunile de date sunt efectiv „Private” - chiar și sesiunea de date #1.

Cum mă pot asigura că comenzile SET se aplică unei sesiuni de date private?

Aceasta este de fapt o întrebare complexă și răspunsul, așa cum deseori în VFP, este „depinde”. În mod normal, veți folosi sesiuni de date care sunt create de un formular (sau set de formulare) ca „Private”. De asemenea, contează dacă utilizați sau nu DataEnvironmentul nativ al formularului. În orice caz, este important să înțelegeți ordinea în care se întâmplă lucrurile - secvența de mai jos arată cum este inițializat un formular cu o sesiune de date privată și un tabel în DE nativ:

METODA: DATAENVIRONMENT.OPENTABLES()

SESIUNEA DE DATE: 2

ALIAS(): <Niciunul>

METODA: DATAENVIRONMENT.BEFOREOPENTABLES()

SESIUNEA DE DATE: 2

ALIAS(): <Niciunul>

METODA(): FORM.LOAD()

SESIUNEA DE DATE: 2

ALIAS(): <TableName>

METODA: DATAENVIRONMENT.INIT()

SESIUNEA DE DATE: 2

ALIAS(): <TableName>

Observați că DataSession este întotdeauna 2, noua Private DataSession și că tabelul este deja disponibil în DataSession atunci când se declanșează evenimentul Load().

Anomalia că OpenTables() apare înainte de BeforeOpenTables() este mai aparentă decât reală și este prilejuită de faptul că evenimentul BeforeOpenTables() este de fapt declanșat de metoda OpenTables().

Este necesară o notă aici pentru a explica terminologia pe care o folosim pentru „Evenimente” și „Metode”. Din păcate, Visual FoxPro folosește ambii termeni în Foaia de proprietăți, ceea ce poate fi confuz. De fapt, este de fapt destul de simplu, deoarece nu poți, în Visual FoxPro, nici să creezi sau să modifici un „Eveniment”, doar codul metodei „asociat CU acel eveniment”. Acest lucru înseamnă că accesarea „<xxx> Evenimentul” din foaia de proprietăți vă duce de fapt la „Metoda <xxx>”. Practica pe care am adoptat-o de-a lungul cărții este, prin urmare, să ne referim la „METODA <xxx>” atunci când vorbim despre locul în care scrieți codul și la EVENIMENTUL <xxx> când ne referim la acțiune sau „declanșator” ceea ce face ca acel cod să fie executat.

Deci, dacă trebuie să modificați în mod explicit setările care se aplică modului în care sunt gestionate tabelele (de exemplu, MultiLocks), trebuie să faceți acest lucru în codul BeforeOpenTables() al DataEnvironment - orice

altfel este prea târziu pentru că DataSession este deja prezentă, cu tabelele deschise, până când se declanșează prima metodă bazată pe formular (Load()).

Acest lucru prezintă o problemă deoarece o clasă de formulare VFP nu are un mediu de date, deci nu puteți adăuga cod la clasa din care creați formularele. Există într-adevăr doar două soluții dacă trebuie să utilizați DataEnvironment al formularului și ambele necesită cod, sau mai precis o acțiune în fiecare instanță a unui formular:

• 	Adăugați codul relevant (sau un apel la o procedură) la evenimentul BeforeOpenTables() al fiecărui formular

• 	Nu permiteți mediului de date nativ să vă deschidă automat tabelele. Setați AutoOpenTables = .F. și apelați metoda OpenTables() în mod explicit din interiorul Form Load()

Adăugarea codului la BeforeOpenTables()

Acest lucru este foarte simplu, dar trebuie făcut în fiecare instanță a formularului. Pur și simplu deschideți Form DataEnvironment în designer și adăugați orice setări de mediu aveți nevoie direct la metoda BeforeOpenTables. Alternativ, puteți plasa codul relevant într-o procedură și îl puteți apela din metodă sau puteți crea o clasă de setare a mediului (vezi mai jos) și să o instanțiați folosind metoda AddObject() din Form. (Un DataEnvironment are un AddObject() propriu, dar puteți adăuga doar obiecte bazate pe clasele Cursor și Relation direct în DataEnvironment.)

O sugestie suplimentară, dacă adoptați această metodologie, este să plasați codul în evenimentul Load() al clasei dvs. de formular, care verifică o anumită setare și, dacă nu este găsită, afișează un MessageBox. Prin urmare:

IF This.DataSessionId # 1

*** Avem o sesiune de date privată

IF SET ( 'MULTILOCKS' ) = 'OFF'

*** Sau orice setare pe care o setați ÎNTOTDEAUNA!

IcText = "Nu ați setat codul BeforeOpenTables() Up"

CUTĂ DE MESAJ(IcText, 16, „Gesură dezvoltatorului!”)

ENDIF

ENDIF

Suprimarea tabelelor cu deschidere automată

Dacă doriți să utilizați metoda de încărcare a formularului pentru a seta opțiuni pentru o sesiune de date, mai întâi trebuie să suprimați comportamentul implicit al mediului de date, care este de a deschide automat tabelele. Aceasta este o chestiune simplă de a seta proprietatea AutoOpenTables la false în DataEnvironment, dar din nou trebuie făcută explicit în fiecare instanță a formularului. Odată ce ați suprimat această proprietate, puteți introduce cod în metoda de încărcare a formularului fie pentru a apela o procedură, fie o metodă de formular, care se va ocupa de setarea mediului. Metoda noastră preferată este să folosim o clasă de setare a mediului și pur și simplu să instanțiem un obiect bazat pe acea clasă direct în metoda Load a formularului, așa cum este ilustrat în secțiunea următoare.

Crearea unei clase de setare a mediului

Credem că cea mai bună metodă de a vă configura propriul mediu într-o sesiune de date privată este să folosiți o clasă. Prin plasarea tuturor comenzilor SET necesare într-o metodă care este apelată de Init

metoda clasei, simpla instanțiere a unui obiect bazat pe această clasă va configura lucrurile așa cum doriți. Codul pentru a face acest lucru poate fi apoi plasat în metoda Load a clasei dvs. de formular, astfel încât de fiecare dată când formularul este instanțiat, să fie aplicate setările corecte. Singura limitare a acestei metodologii este că, după cum sa menționat mai sus, nu puteți permite DataEnvironment să gestioneze automat deschiderea tabelelor. Următorul cod arată cum o astfel de clasă poate fi definită programatic (deși nu există niciun motiv pentru care o astfel de clasă să nu fie creată în designerul de clasă vizuală):

**************************************************** ****************************

* 	Program. EnvSet.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Definiție de clasă pentru stabilirea opțiunilor de mediu. Instanciarea

* 	..........: clasa stabilește opțiunile necesare. Metoda GetOption() arată

* 	..........: cum poate fi folosit obiectul și pentru a prelua setările.

**************************************************** ****************************

DEFINEȚI CLASA cusEnvSet CA personalizat ********************************************* ******************************** *** Init apelează doar metoda SetOptions().

**************************************************** ****************************

PROCEDURA Init

This.SetOptions()

ENDPROC

**************************************************** ****************************

*** Setează opțiunile de mediu necesare

**************************************************** ****************************

PROCEDURA SetOptions

*** Închidere și mediu

OPRITĂ VORBIREA

ACTIVATĂ MULTILOCK

SETATI REPROCESAREA LA AUTOMAT

SETARE ȘTERGĂ PE

DEZACTIVAȚI SIGURANȚA

OPRIȚI SLOPERUL

SETĂ ECHO OFF

DEZACTIVATĂ NOTIFICARE

SETARE CONFIRMARE OFF

SETĂ EXACT OFF

SETARE REFRESH LA 60,60

ACTIVATĂ BARA DE STARE

*** Cale

*** Data și moneda

PUNEȚI SECOLUL

SETĂ CENTURY LA 19 ROLLOVER 75

SETĂ DATA LA BRITANICA

SETĂ MONETA LĂSĂ

SETĂ MONEDA LA „£”

ENDPROC

**************************************************** ****************************

*** Returnează setarea curentă a unei opțiuni de mediu

**************************************************** ****************************

PROCEDURA GetOption( tcOption )

LOCAL luRetVal, IcOption

STOCAZĂ „” LA luRetVal

lcOption = UPPER(ALLTRIM(tcOption ))

*** Dacă ni s-a oferit o setare, obțineți starea actuală

*** NOTĂ: Dacă este într-adevăr nevoie, această metodă ar necesita mai multe verificări

*** și opțiuni, deoarece nu orice setare poate fi pur și simplu returnată

*** prin funcția SET() - dar asta ilustrează ideea!

DACĂ VARTYPE( lcOption ) = "C" ȘI ! EMPTY(lcOption)

luRetVal = SET(lcOption)

ENDIF

RETURN luRetVal

ENDPROC

ENDDEFINE

Pentru a utiliza această clasă, pur și simplu adăugați următorul cod la metoda Load a clasei dvs. Form:

*** Adăugați obiect pentru a seta mediul (suprimați orice afișare în mod explicit)

OPRITĂ VORBIREA

DACĂ ! "ENVSET" $ UPPER( SET('PROCEDURA'))

SETĂ PROCEDURA LA ADDITIVUL envset

ENDIF

This.AddObject( "oCusEnv", "CusEnvSet")

Aceasta va instanția obiectul, setând astfel opțiunile definite și, în același timp, va crea o referință pe formular, astfel încât orice metode suplimentare pe care le-ați definit (de exemplu metoda GetOption() prezentată mai sus) să poată fi accesate.
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Cum scap de barele de instrumente ale sistemului?

Când porniți Visual FoxPro, una sau mai multe dintre barele de instrumente ale sistemului vor fi în mod normal vizibile. (Starea actuală a barei de instrumente este stocată în fișierul de resurse.) Din fericire, toate barele de instrumente ale sistemului pot fi adresate folosind numele ferestrelor lor (care sunt de fapt aceleași cu subtitrările lor) și astfel manipularea lor este relativ simplă.

Cel mai simplu mod de a vă asigura că sunt vizibile doar acele bare de instrumente de care aveți nevoie este să creați o matrice cu toate numele barelor de instrumente, apoi să treceți prin ele, testând pentru a vedea dacă fiecare este vizibilă și ascundeți pe cele care nu sunt necesare. Următorul cod va ascunde toate barele de instrumente vizibile ale sistemului:

DIMENSIUNE laTbState[11]

laTbState[

1]="Paletă de culori"

laTbState[

2]="Database Designer"

laTbState[

3]="Controale formulare"

laTbState[

4]="Designer de formulare"

laTbState[

5]="Aspect"

laTbState[

6]="Previzualizare tipărire"

laTbState[

7]="Designer de interogări"

laTbState[

8]="Controale raportate"

laTbState[

9]="Designer de rapoarte"

laTbState[10]="Standard"

laTbState[11]="View Designer"

PENTRU lnCnt = 1 LA 11

IF WEXIST(laTbState[lnCnt])

Ascunde fereastră ( laTbState[lnCnt] )

ENDIF

URMĂTORUL

Desigur, acest lucru ridică problema a ceea ce se întâmplă dacă apoi doriți să reafișați o bară de instrumente a sistemului.

Poate deloc surprinzător, comanda SHOW WINDOW poate fi folosită pentru a re-afișa o bară de instrumente de sistem ascunsă anterior, în timp ce RELEASE WINDOW va elibera de fapt bara de instrumente specificată.

Bara de instrumente a sistemului „Am înțeles!”

Dar există o captură! Pentru a utiliza Show Window, fereastra numită trebuie să fi fost definită la VFP și chiar dacă barele de instrumente de sistem sunt generate de VFP, nu există nicio modalitate de a defini sau activa efectiv barele de instrumente în mod programatic. Consecința este că, cu excepția cazului în care o bară de instrumente este activată mai întâi de VFP, nu o puteți face vizibilă ulterior. Singurele bare de instrumente care pot fi făcute vizibile în mod implicit sunt „Standard”, „Layout” și „Form Designer”, dar nu pare să existe vreo modalitate fiabilă de a forța programatic oricare dintre celelalte bare de instrumente ale sistemului să fie vizibile la pornire.
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Pot folosi macrocomenzile de la tastatură în VFP?

Răspunsul scurt este da. De fapt, una dintre capabilitățile adesea uitate ale Visual FoxPro este capacitatea sa de a utiliza macrocomenzi de la tastatură. Acestea, cu puțină gândire, vă pot face viața de dezvoltator mult mai ușoară atunci când atribuiți propriile taste specifice unei combinații de taste simple. De exemplu, în loc să rulați un program de „resetare” pentru a închide tabele și baze de date, a elibera bibliotecile de clase și a restabili meniul FoxPro implicit, puteți programa comenzile necesare pe tasta funcțională F2 astfel:

SETĂ FUNCȚIA F2 LA „ȘTERGE TOTUL ;” ;

+ "SETARE CLASĂ LA ;" ;

+ "SETARE PROC LA ;" ;

+ „ÎNCHIDE TOATE ;” ;

+ "SETARE SYSMENU LA IMPLICIT ;" ;

+ "ACTIVARE COMANDA FEREASTRĂ;"

Desigur, puteți utiliza și Editorul de macrocomenzi (invocat din opțiunea Instrumente\Macrocomenzi din meniul principal) pentru a vă crea macrocomenzi. Macrocomanda creată de comanda de mai sus este vizibilă și editabilă în Editorul Macro ca:

Șterge{ BARA DE SPAȚIU}TOATE{ BARA DE SPAȚIU}{ENTER}

SETAZĂ { BARA DE SPAȚIU} CLASSLIB{BARRA DE SPAȚIU} LA{ BARA DE SPAȚIU} {ENTER}

SETĂ{BARA DE SPAȚIU}PROC{BARA DE SPAȚIU}LA{BARA DE SPAȚIU}{ENTER}

ÎNCHIDE{BARA DE SPAȚIU}TOATE{ BARA DE SPAȚIU}{ENTER}

SETATE { SPAȚIU} SYSMENU{ SPAȚIU} LA{ SPAȚIU} IMPLICIT { SPAȚIU} {ENTER}

ACTIVAȚI COMANDA { BARA DE SPAȚIU}FERASTRĂ{ BARA DE SPAȚIU}{ENTER}

Cum pot construi o macrocomandă mai complexă?

Puteți folosi facilitatea de macro „înregistrare” (da, la fel ca în Word sau Excel!) pentru a vă scuti de durerea de a afla exact cum să scrieți comenzile necesare de la tastatură. În mod normal, folosim un fișier de program gol pentru a face acest tip de lucru, așa cum ilustrează următorii pași:

• 	Deschideți un fișier PRG (MODIFICARE COMANDĂ)

• 	Alegeți Instrumente, Macro-uri, Înregistrare din meniul Sistem principal

• 	Scrieți codul ca de obicei

• 	Alegeți Instrumente, Macro-uri pentru a opri înregistrarea

• 	Testează-ți macrocomanda!

Folosind această tehnică, următorul cod pentru a scrie un handler simplu de mesaje Da/Nu (și a lăsa cursorul poziționat între primul set de ghilimele din apelul funcției MessageBox) a fost atribuit tastei F9. Codul scris a fost:

LOCAL lnOpt

lnOpt = MessageBox( 36, '' )

DACĂ lnOpt = 6 && DA

ENDIF

Și macro-ul rezultat a fost:

LOCAL{ SPAȚIU}lnOpt{ENTER} lnOpt{SPAȚIU}={SPAȚIU}MessageBox({SPAȚIU} ' ' , { SPAȚIU} 36 , { SPAȚIU} ' ' { SPAȚIU} ) {ENTER} IF{SHIFT+SPAȚIU}lnOpt{SPAȚIU }={SPAȚIU}6 {TAB}&&{ SPAȚIU}DA{ENTER}

{INTRODUCE}

ENDIF{UPARROW}{UPARROW}{UPARROW} {END}{LEFTARROW}{LEFTARROW}{LEFTARROW}

{LEFTARROW} {LEFTARROW} {LEFTARROW} {LEFTARROW} {LEFTARROW} {LEFTARROW} {LEFTARROW}

{LEFTARROW}{LEFTARROW}

Ce este un „Set Macro”?

Visual FoxPro vă permite să definiți și să salvați „seturi” de macrocomenzi. Acestea sunt stocate într-un format de fișier special cu o extensie implicită „.FKY (fișierul Ajutor are un subiect dedicat structurii fișierului FKY). Puteți crea mai multe seturi de macrocomenzi și le puteți salva în fișiere care pot fi încărcate și descărcate prin editorul de macrocomenzi. De asemenea, puteți specifica un set de macrocomenzi „dezvoltator” ca valori implicite care să fie încărcate automat la pornirea Visual FoxPro. (Deși dacă adoptați această abordare, vă sfătuim să includeți o comandă clară de macrocomandă în toate programele de pornire a aplicației.) Câteva macrocomenzi „dezvoltator” pe care le-am găsit utile sunt:

• 	Inserați WITH This... .ENDWITH (ALT+T)

CU{ BARA DE SPAȚIU}Acest{ENTER}

{INTRODUCE}

TERMINAT CU{UPARROW}{TAB}

• 	Inserați WITH ThisForm...ENDWITH (ALT+F)

CU{ BARA DE SPAȚIU}ThisForm{ENTER}

{INTRODUCE}

TERMINAT CU{UPARROW}{TAB}

• 	Introduceți paranteze între ghilimele ("") (alt+b)

(" " ) {LEFTARROW}{LEFTARROW}

• 	Introduceți o comandă WAIT "" WINDOW NOWAIT (ALT+W)

Așteptați{ BARA DE SPAȚIU}""{BARA DE SPAȚIU}FERASTRĂ{ BARA DE SPAȚIU}ACUM Așteptați

{LEFTARROW}{LEFTARROW}{LEFTARROW}LEFTARROW}{LEFTARROW STÂNGA}{LEFTARROW}

{LEFTARROW}{LEFTARROW}{LEFTARROW}LEFTARROW}{LEFTARROW STÂNGA}{LEFTARROW}

{LEFTARROW}{LEFTARROW}{LEFTARROW}LEFTARROW}{LEFTARROW STÂNGA}{LEFTARROW}

Deschideți fereastra „Găsiți următorul” și inserați textul evidențiat (SHIFT+ALT+F)

{CTRL+C}{CTRL+HOME}{CTRL+F}{CTRL+V}{TAB}{BACKSPACE}{CTRL+ENTER}

Sfera de a crea comenzi rapide personalizate ca acestea este limitată doar de imaginația dvs., dar vă poate îmbunătăți foarte mult productivitatea atunci când scrieți cod sau chiar atunci când lucrați interactiv prin fereastra de comandă.

În cele din urmă, verificați, de asemenea, comanda PLAY MACROS, care vă permite să rulați macrocomenzi în mod programatic (pentru a crea demonstrații cu rulare automată sau chiar scripturi de testare simple), deși comportamentul acestei comenzi are unele ciudații proprii.

Care este diferența dintre o macrocomandă și o etichetă On Key Label?

Diferența cheie este că o macrocomandă este doar un program Visual FoxPro care transmite în flux intrarea de la tastatură. În acest sens, nu este diferit de orice alt program și rulează în bucla normală de evenimente Visual FoxPro. O etichetă On Key, pe de altă parte, funcționează în afara procesării normale a evenimentelor și permite executarea unei anumite comenzi chiar și atunci când VFP este implicat în mod aparent într-o altă sarcină. Acest lucru poate fi foarte util, dar este și potențial periculos! Următorul mic program ilustrează clar diferența de comportament. Eticheta On Key Label va întrerupe imediat comanda de citire în așteptare și va suspenda programul, în timp ce Macro-ul tastaturii este pur și simplu ignorat:

**************************************************** ****************************

* 	Program. MACOKL.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Ilustrați diferența dintre o macrocomandă de tastatură

* 	..........:și o comandă On Key Label. Introdu „99” pentru a ieși din fiecare buclă

* 	..........:si continua cu programul!

**************************************************** ****************************

*** Definiți o etichetă On Key

PE CHEIE LABEL F10 SUSPEND

CLAR

*** Inițializați tamponul cheii

LnKey LOCAL

lnKey = 0

*** Start Loop - Folosiți 99 pentru a ieși

FĂ CÂND .T.

*** Verificați „x” pentru a ieși

? „În interiorul unei bucle OKL”

@ 10,10 GET lnKey PICT „99”

CITIT

IF lnKey = 99

IEȘIRE

ENDIF

ENDDO

*** Ștergeți OKL

PE CHEIE LABEL F10

CLAR

*** Acum definiți o macrocomandă a tastelor funcționale

SETĂ FUNCȚIA 10 LA „SUSPENDERE;”

*** Inițializați tamponul cheii

lnKey = 0

*** Start Loop - Folosiți 99 pentru a ieși

FĂ CÂND .T.

*** Verificați „x” pentru a ieși

? „În interiorul unei bucle F10”

@ 10,10 GET lnKey PICT „99”

CITIT

IF lnKey = 99

IEȘIRE

ENDIF

ENDDO

*** Ștergeți macrocomanda

SETĂ FUNCȚIA 10 LA ""

În mod clar, deoarece On Key Labels poate funcționa în afara mecanismelor normale de gestionare a evenimentelor, impactul lor asupra codului care se execută deja poate fi imprevizibil. Mai mult, Etichetele On Key pot fi apelate în mod repetat, cu excepția cazului în care includeți comenzile de ștergere a tastei apăsare/Ștergere a tastei pop pentru a dezactiva eticheta OnKey în sine în timp ce rutina pe care o apelează este procesată.

Din aceste motive, recomandăm cu tărie împotriva utilizării lor fără discernământ în aplicații, mai ales că există aproape întotdeauna o modalitate alternativă (de obicei prin utilizarea codului în metoda KeyPress) de a gestiona tastele speciale.
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Cum creez un ecran „Splash”?

Aceasta este una dintre sarcinile pe care Visual FoxPro Versiunea 6.0 le gestionează puțin mai bine decât predecesorii săi. Primul lucru care este necesar este un formular care nu are o bară de titlu și formularul normal Controls. În versiunea 6.0, proprietatea TitleBar a fost adăugată la clasa Form și pur și simplu setând TitieBar = .f. vă oferă o formă simplă. În versiunile anterioare ale VFP există o serie de proprietăți care trebuie setate pentru a obține același rezultat:

Subtitrare = " "

ControlBox = .F.

Închidebil = .F.

MaxButton = .F.

MinButton = .F.

Mobil = .F.

Formularul ar trebui, de asemenea, configurat ca formular de nivel superior ( ShowWindow = 2, AlwaysOnTop = .T. ). Ceea ce intră în formular depinde de cerințele dvs., dar de obicei va include un fel de grafic și probabil ceva text. De asemenea, este posibil să doriți să adăugați fie un temporizator, fie un cod pentru a permite utilizatorului să șterge în mod explicit ecranul de introducere.

Cum îmi rulez ecranul de deschidere?

Cel mai eficient mod de a rula un ecran de introducere este:

• 	Includeți „SCREEN = OFF” în fișierul de configurare

• 	Rulați formularul de tip splash ca prima linie a pornirii aplicației

• 	Faceți orice configurație este necesară - inclusiv meniul inițial

• 	Restabiliți fereastra VFP principală și eliminați ecranul Splash

• 	Porniți bucla de evenimente a aplicației

Fragmentul de cod de mai jos arată cum ar arăta programul de pornire în practică:

*** Afișează ecranul de deschidere

DO FORM splash NAME splash LEGAT

*** Faceți orice lucru de configurare aici

*** La finalizare

*** Restaurați ecranul/meniul VFP dacă este necesar

DO <mainmenu.mpr>

_SCREEN.WINDOWSTATE = 2

_ECRAN.VIZIBIL = .T.

*** Eliminați ecranul de splash când este gata

ELIBERĂ stropire

*** Porniți bucla de evenimente a aplicației

CITEȘTE EVENIMENTE

O alternativă la ecranul de splash

Dacă aplicația dvs. va folosi fereastra principală Visual FoxPro ca desktop, atunci mai degrabă decât să utilizați un formular ca ecran de introducere, este mai simplu să adăugați un obiect direct pe ecranul VFP și să îl eliminați când este gata. Obiectul Visual FoxPro Screen are ambele metode AddObject() și RemoveObject() care pot fi apelate din cadrul programelor dumneavoastră.

Tot ceea ce este necesar este să creați o clasă container care să includă graficul și orice alte controale și să o adăugați direct pe ecran. Odată ce configurarea aplicației dvs. este finalizată, obiectul poate fi pur și simplu eliminat. Acest lucru este mai simplu de implementat, deoarece nu necesită ca ecranul să fie oprit la pornire, așa cum arată următorul fragment de cod:

*** Maximizați ecranul

CU _Ecran

.WINDOWSSTAT = 2

*** Adăugați containerul

SETĂ CLASSLIB LA fișierele splash

.AddObject( 'cntSplash', 'xCntSplash' )

*** Raportați progresul

CU .cntSplash.txtProcess

.Value = „Se încarcă biblioteci de clasă”

*** Încărcați bibliotecile aplicației

.Value = „Inițializarea datelor”

*** Configurați DBC

*** Configurați meniuri și așa mai departe...

SE TERMINA CU

.RemoveObj ect( 'cntSplash' )

SE TERMINA CU

*** Porniți bucla de evenimente a aplicației

CITEȘTE EVENIMENTE

(Notă: presupunem că definiția clasei include setările Sus/Stânga și o comandă This.Visible = .T. în metoda Init() a containerului, astfel încât nu este nevoie să faceți obiectul vizibil sau să-l repoziționați , în codul aplicației.)
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Cum să tapeți desktopul

Adăugarea unui fundal (de exemplu, un logo al companiei) pe desktop-ul aplicației dvs. poate adăuga un aspect „profesional” aplicației dvs. VFP. Cu toate acestea, nu este întotdeauna atât de ușor pe cât pare la prima vedere. Principiul de bază este destul de ușor - pur și simplu setați proprietatea Picture a obiectului _Screen al Visual FoxPro la bitmap-ul necesar.

Problema este că comportamentul implicit este de a „tigla” bitmap-ul dacă dimensiunile sale nu se potrivesc exact cu dimensiunea zonei disponibile a ecranului în rezoluția selectată în prezent. Rezultatul este că ceea ce funcționează la rezoluția de 800 x 600, să zicem, nu va arăta corect nici la rezoluții mai mari sau mai mici. Mai mult, zona disponibilă depinde dacă aveți bara de stare activată sau dezactivată, dacă aveți un meniu afișat și dacă aveți barele de instrumente andocate sau nu. Deci, pentru a face lucrurile corect, se pare că trebuie să cunoașteți dimensiunea reală a desktop-ului la diferite rezoluții și să creați un bitmap de dimensiuni adecvate pentru fiecare posibilitate.

Deci, cum pot obține dimensiunea zonei curente _Screen?

Funcțiile SCOLS() și SROWS() ale Visual FoxPro returnează numărul de coloane și rânduri din zona curentă a ecranului (pe baza fontului de afișare selectat). Deci, pentru a determina, în pixeli, dimensiunea zonei de afișare, trebuie să utilizați și funcția Fontmetric(), după cum urmează:

InScreenHeight = SROWS()* FONTMETRIC(1, _screen.fontname, _screen.fontsize)

InScreenWidth = SCOLS()* FONTMETRIC(6, _screen.fontname, _screen.fontsize)

Folosind aceste formule, obținem următoarele rezultate cu un meniu pe o singură linie vizibil:

Tabelul 1.2. Înălțimile ecranului disponibile la diferite rezoluții cu fontul ecranului setat la Arial 10pt

a ecranului 	= ON 		Bara de stare = OFF	
Rezoluție 	Docked TbarUnDocked TbarDocked TbarUnDocked Tbar
1024x768 	646678670702
800 x 600 	478510502534
640 x 480 	358390382414

Lățimea ecranului este (cu excepția cazului în care barele de instrumente sunt andocate în partea laterală a ecranului) întotdeauna aceeași cu rezoluția orizontală. Când vă proiectați aplicația, va trebui, desigur, să utilizați un singur set de valori, deoarece veți porni întotdeauna aplicația în același mod (în ceea ce privește meniurile, barele de instrumente și barele de stare).

Dacă acum ar fi să creați o serie de hărți de bit, dimensionate corect pentru fiecare rezoluție, puteți pur și simplu să setați proprietatea Screen.Picture la cea corespunzătoare la pornirea aplicației.

Chiar trebuie să creez toate aceste bitmap-uri?

Ei bine, de fapt, răspunsul este posibil să nu fie! Există o strategie alternativă, deși succesul acesteia va depinde de natura imaginii pe care doriți să o afișați. Puteți crea pur și simplu o clasă (pe baza clasei de bază a imaginii, numită, de exemplu, almgWallPaper) care are proprietatea Picture setată la un singur bitmap și proprietatea Stretch setată la 2 (extinde pentru a umple controlul). Adăugați o metodă numită „AdjustSize” și apelați-o din metoda Init a acestei clase. Ar trebui codificat astfel:

Cu asta

.Înălțime = FONTMETRIC(1, _SCREEN.FONTNAME, _SCREEN.FONTSIZE) * SROWS()

.Width = FONTMETRIC(6, _SCREEN.FONTNAME, _SCREEN.FONTSIZE) * SCOLS()

.Vizibil = .T.

SE TERMINA CU

Acum, la pornirea aplicației, adăugați pur și simplu un obiect bazat pe această clasă direct pe ecran, imediat înainte de a executa evenimentele dvs., după cum urmează:

_Screen.AddObject( 'oWallPaper', 'almgWallPaper')

Imaginea se va auto-dimensiona pentru a umple zona disponibilă a ecranului, oferind aplicației dvs. un aspect cu adevărat profesional. Singurul lucru de urmărit este că, dacă bitmap-ul dvs. nu este simetric, setarea întinderii imaginii = 2 poate da o imagine distorsionată. O posibilă soluție este să utilizați stretch = 1 (izometric) care va păstra proporția relativă a bitmap-ului original, dar este posibil să nu umple în întregime ecranul atunci când este redimensionat. Cel mai bun sfat aici este să experimentezi.

O bară de instrumente „Am înțeles!”

O problemă cu utilizarea imaginilor de fundal împreună cu barele de instrumente este că andocarea și dezactivarea unei bare de instrumente modifică zona vizibilă a ecranului, dar nu și dimensiunea imaginii. Gestionarea andocării unei bare de instrumente este destul de simplă, deoarece evenimentul _Screen.Resize() este declanșat după evenimentul BeforeDock() al barei de instrumente, dar înainte de evenimentul AfterDock(). De fapt, instrumentul de urmărire a evenimentelor indică faptul că evenimentul Redimensionare se declanșează de două ori! (Se presupune că acest lucru este astfel încât ecranul să se redimensioneze atunci când bara de instrumente este mutată din zona ecranului principal în bara de titlu și din nou după ce este de fapt andocat). Deci metoda dvs. de imagine „AdjustSize” poate fi apelată din evenimentul AfterDock() al barei de instrumente pentru a gestiona corect andocarea, astfel:

IF VARTYPE( _Screen.oWallPaper ) = 'O'

CU Ecran

.Ecran de blocare

.T.

.oWallPaper.AdjustSize() .LockScreen = .F.

SE TERMINA CU

ENDIF

Din păcate, se pare că dezactivarea unei bare de instrumente nu declanșează deloc evenimentul _Screen.Resize()! Deși ecranul se redimensionează de fapt atunci când o bară de instrumente este deconectată, noua dimensiune nu este disponibilă pentru nicio metodă care poate fi apelată din bara de instrumente. Credem că aceasta trebuie să fie o eroare, deoarece un apel explicit la metoda AdjustSize (din afara barei de instrumente) după terminarea dezandocării, recalculează dimensiunea corect și ajustează imaginea în mod corespunzător. Nu avem o soluție satisfăcătoare pentru această problemă, în afară de a evita barele de instrumente mobile atunci când folosim imagini de fundal pentru desktop care nu sunt definite direct în proprietatea Imagine.
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Îmbunătățirea mediului de dezvoltare

Unul dintre pericolele pe care le puteți întâlni ocazional când dezvoltați în Visual FoxPro este că unul dintre programele dvs. se va bloca. (Știm că acest lucru este extrem de rar, dar suntem siguri că se întâmplă cu adevărat și altor persoane din când în când.) Într-o astfel de situație, este util să aveți o modalitate simplă de curățare și de a vă întoarce la punctul de plecare. Ne place să folosim un mic program numit ClearAll' pentru a gestiona acest lucru pentru noi, care se asigură că totul este închis și curățat corespunzător.

Primul lucru pe care îl face acest program este să dezactiveze orice gestionare a erorilor. Acest lucru ne va permite să forțăm orice comenzi anormale (cum ar fi selectarea unei sesiuni de date care nu există) fără întrerupere - la urma urmei, de când ne curățăm, nu ne mai pasă de erori!

**************************************************** ********************

* 	Program.ClearAll.PRG

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Curăță mediul de dezvoltare

**************************************************** ********************

LOCAL lnCnt, lnCntUsed

MATRICE LOCALĂ laUtilizat[1]

*** Dezactivați gestionarea erorilor pentru moment

LA EROARE *

În continuare, ștergem ecranul și postăm o fereastră de așteptare, înainte de a anula orice tranzacție deschisă:

*** Șterge ecranul

CLAR

FEREASTRA Așteptați „Se șterge... vă rog așteptați...” ASTEPTĂ ACUM

*** Derulați înapoi orice tranzacție

DACĂ TXNLEVEL () > 0

FACEȚI CÂND TXNLEVEL() > 0

ROLLBACK

ENDDO

ENDIF

Acum trebuie să ne ocupăm de orice modificări necommitate. Desigur, nu putem ști câte formulare pot fi deschise sau ce sesiune de date folosește de fapt fiecare formular. Soluția este să folosiți colecția Forms și să lucrați prin sesiunea de date a fiecărui formular, reîntoarcerea tuturor tabelelor din acea sesiune de date și închiderea lor înainte de a elibera formularul în sine.

*** Reveniți tabelele și închideți-le

PENTRU FIECARE loForm ÎN _Screen.Forms

*** Aflați în ce Datasession este

lnDS = loForm.DataSessionID

*** Are mese deschise?

lnCntUsed = AUSED(laUsed, lnDS)

DACĂ LnCntUsed > 0

SETĂ SESIUNEA DE DATE LA (lnDS)

*** Dacă da, anulați toate modificările neconfirmate

FOR InCnt = 1 TO InCntUsed

SELECTARE (laUsed[lnCnt,2])

IF CURSORGETPROP('Buffering') > 1

=TABLEREVERT( .T. )

ENDIF

UTILIZARE

URMĂTORUL

ENDIF

*** Și eliberați formularul

loForm. Eliberare()

URMĂTORUL

După ce am scăpat de formulare, acum putem închide toate tabelele rămase și bazele de date asociate acestora și putem șterge orice program din memorie, variabile de memorie și biblioteci:

*** Acum Închideți alte tabele și baze de date

ÎNCHID MABELE TOATE

ÎNCHID TOATE DATELE

*** Eliberare variabile de memorie, proceduri

*** și biblioteci de clasă

ȘTERGE MEMORIA

CURATA TOT

SETĂ PROCEDURA LA

SETĂ CLASĂ LA

Cu toate acestea dispărute, putem restabili în siguranță fereastra de comandă și meniul implicit de sistem și putem șterge toate setările globale definite folosind comenzile ON:

*** Obțineți fereastra de comandă și meniul de sistem înapoi

ACTIVAȚI COMANDA PE FEREASTRĂ

SETATE SYSMENU LA IMPACT

*** Ștergeți setările globale

ÎN OPRIRE

LA EROARE

PE CHEIE

LA ESCAPARE

Așteptați clar

Pasul final este anularea oricăror programe deschise (inclusiv acesta). Acest lucru este necesar pentru a vă asigura că toate formularele care au apelat dialoguri modale sunt eliberate corespunzător:

*** Anulați orice program deschis

ANULARE
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Se închide VFP

Până acum ne-am concentrat pe configurarea și gestionarea mediului Visual FoxPro, cu toate acestea, modul în care închideți Visual FoxPro este la fel de important. În mediul de rulare există două moduri de a iniția procesul de închidere. În primul rând prin utilizarea comenzii CLEAR EVENTS, fie în cadrul unui meniu, fie în metoda Eliberare a unui formular. În al doilea rând, prin butonul de închidere a ferestrelor standard al ferestrei principale Visual FoxPro. Din fericire, Visual FoxPro ne oferă un handler global pentru procesul de închidere, indiferent dacă acesta este inițiat - comanda on SHUTDOWN.

Ce este o procedură On ShutDown?

Ca și alte comenzi ON, comanda ON SHUTDOWN este implementată de un handler special care se află în afara buclei normale de procesare a evenimentelor Visual FoxPro. Când este invocat, controlul este transferat imediat la orice comandă sau funcție care a fost specificată ca țintă. Acesta este de departe cel mai bun mod (dacă nu singurul) de a vă asigura că Visual FoxPro se închide curat, fără a irita mesajul „Cannot Quit Visual FoxPro”.

Ce declanșează o procedură On Shutdown?

Comanda specificată în oprire este executată dacă încercați să părăsiți Visual FoxPro făcând clic pe butonul „Închidere” din ecranul principal Visual FoxPro, alegând Ieșire din meniul de control FoxPro sau lansând comanda de ieșire într-un program (sau fereastra de comandă!). În plus, va fi declanșat dacă încercați să părăsiți Windows în timp ce Visual FoxPro este deschis. (Controlul este returnat la Visual FoxPro și se execută procedura ON SHUTDOWN specificată.)

Ce se înscrie într-o procedură de închidere?

Procedura apelată de o comandă ON SHUTDOWN conține orice puteți plasa legal într-un program Visual FoxPro, cu excepția comenzilor de suspendare sau anulare (ambele vor provoca o eroare), dar cel puțin trebuie să se ocupe de următoarele probleme:

• 	Închideți orice tranzacție deschisă

• 	Commiteți sau anulați orice modificări în așteptare în tabele sau vizualizări

• 	Închideți toate formularele (un formular modal deschis este una dintre cauzele mesajului „Cannot Quit”)

• 	Emite un Evenimente clare (o CITIRE EVENIMENTE activă este o altă cauză a mesajului „Nu se poate ieși”)

• 	Restaurați mediul de dezvoltare (dacă nu rulați un fișier APP sau .exe) SAU

• 	Închideți Visual FoxPro (dacă rulați un fișier APP sau .exe)

Comportamentul în VFP3.0 a fost că o comandă QUIT ar închide formularele Modal deschise și ar anula orice EVENIMENTE DE CITIRE existente. Acesta nu este cazul nici în versiunea 5.0, nici în versiunea 6.0.

Veți observa că aceste elemente sunt aproape identice cu cele pe care le-am plasat în „ClearAll.prg” pentru curățarea mediului de dezvoltare și codul care a fost folosit acolo poate fi folosit, cu modificări minore, ca bază pentru procedura de închidere. .

O astfel de modificare este includerea unui test pentru a determina dacă programul care se execută în prezent a fost de fapt apelat din mediile de dezvoltare sau de rulare. Acesta este unul dintre puținele lucruri pentru care susținem utilizarea unei variabile Public. În programul nostru de pornire a aplicației includem următorul cod:

*** Verificați modul Run

LANSA glExeRunning

PUBLIC glExeRunning

glExeRunning = „EXE” $ UPPER( SYS(16) ) SAU „APP” $ UPPER( SYS(16) )

IF glExeRunning

*** Efectuați pornirea completă, ecranul Splash, autentificare etc

ALTE

*** Porniți în modul de dezvoltare

ENDIF

Deși nu aveți nevoie de o variabilă publică (o variabilă privată normală ar funcționa de fapt aici), ne place să definim astfel de variabile „de sistem” în mod explicit și să le tratăm ca excepții de la regulile generale. După ce am definit variabila, o putem folosi acum în rutina noastră de închidere pentru a determina dacă să ieșim efectiv din Visual FoxPro sau pur și simplu să anulăm programul curent, după cum urmează:

IF glExeRunning

PĂRĂSI

ALTE

ANULARE

ENDIF

Unii oameni susțin, de asemenea, plasarea unei casete de mesaj „Are You Sure” în procedura de închidere - deși aceasta este o chestiune de stil, nu ne place! Ni se pare că nu poate fi nimic mai iritant pentru un utilizator care tocmai a ales în mod specific „Închidere” decât să fie întrebat dacă chiar a vrut să o facă. Dacă interfața dvs. de utilizator este proiectată în așa fel încât un utilizator să vă închidă „accidental” aplicația, vă sugerăm, cu foarte mult respect, că poate fi necesar să re-vizitați designul UI.
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Capitolul 2-Funcții și proceduri

„Putem ierta un om că a făcut un lucru util atâta timp cât nu îl admiră. Singura scuză pentru a face un lucru inutil este că îl admirăm intens” („The Picture of Dorian Gray” de Oscar Wilde)

De câte ori ați moștenit o aplicație de la un alt dezvoltator care a folosit douăzeci de linii de cod când una sau două ar fi fost suficiente? Cât de des ați parcurs kilometri de cod și v-ați întrebat de ce nu a fost împărțit în metode separate pentru a gestiona funcționalitatea discretă? O bibliotecă bine aprovizionată de funcții reutilizabile reduce numărul de linii de cod necesare pentru a îndeplini o anumită sarcină. În plus față de reducerea codului de metodă la nivel de instanță, funcțiile descriptive și numele procedurilor fac codul dvs. mai auto-documentat. În acest capitol vom împărtăși câteva dintre funcțiile interesante pe care le-am descoperit de-a lungul anilor, precum și câteva probleme la care trebuie să fiți atenți. Tot codul din acest capitol este conținut în fișierul de procedură CH02.PRG în subdirectorul cu același nume.
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Cum vom proceda?

În versiunile anterioare ale FoxPro, aplicațiile erau limitate la un singur fișier de procedură activ în orice moment. Aceasta a însemnat că toate funcțiile definite de utilizator și procedurile utilizate în mod obișnuit au fost păstrate într-un singur fișier. Cu Visual FoxPro, capacitatea de a avea mai multe fișiere de procedură active la un moment dat oferă mult mai multă flexibilitate. Astfel de proceduri pot fi acum grupate logic, în funcție de funcționalitate, în diferite fișiere de procedură care pot fi încărcate incremental, după cum este necesar. Dezavantajul, desigur, este că fișierele de procedură sunt încărcate în memorie de Visual FoxPro și păstrate până când sunt eliberate în mod explicit. Aceasta poate să nu fie cea mai bună utilizare a acelei resurse prețioase.

Din fericire, este posibil să se definească și clase de proceduri. Funcțiile individuale care ar fi fost păstrate anterior într-un fișier de procedură pot deveni acum metode ale unei clase. Această abordare are avantajul că, atunci când sunt definite vizual în Class Designer, toate funcțiile din procedură pot fi vizualizate cu atenție în fila Metode din foaia de proprietăți. Clasele de procedură care conțin funcționalitate specifică pot fi plasate pe formulare care necesită această funcționalitate. Un al doilea beneficiu major este că o clasă de procedură poate fi subclasată - pentru acele situații speciale în care funcționalitatea standard trebuie mărită.

Abordarea care ne place este o combinație a acestor două abordări. Vă recomandăm să utilizați un fișier de procedură pentru funcții cu adevărat generice (adică cele care sunt utilizate, neschimbate, de multe aplicații diferite). De exemplu, fișierul nostru de procedură conține o funcție NewID pentru generarea cheilor primare surogat, o funcție SetPath pentru a seta calea pentru aplicație și câteva funcții cheie pe care Visual FoxPro ar trebui să le aibă, dar nu le are. Două exemple de astfel de funcții sunt funcțiile Str2Exp și Exp2Str (utilizate mai târziu în acest capitol Aceste funcții, așa cum sugerează numele, sunt folosite pentru a converti șirurile de caractere în valorile unui alt tip de date specificat și invers.

Clasele de procedură separate conțin funcționalități specifice aplicației. De exemplu, o aplicație de contabilitate poate necesita mai multe funcții pentru a calcula totalul taxelor și facturilor. Clasa de proceduri contabile poate fi plasată pe orice formular care necesită aceste funcții - sau poate fi instanțiată ca obiect la nivel de aplicație. În mod clar, astfel de funcții nu sunt generice și nici măcar nu sunt cerute de întreaga aplicație. Prin gruparea lor într-o singură clasă de procedură, putem face această funcționalitate disponibilă la părțile specifice ale aplicației care o necesită, fără a compromite restul aplicației.
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Parametri (o parte)

Cu toții am folosit parametrii în mod extensiv în FoxPro, dar în mediul orientat pe obiecte al lui Visual FoxPro, parametrii au căpătat o nouă importanță ca mijloc principal de implementare a mesageriei - însăși sângele unei aplicații OO! (Avem mai multe de spus despre acest subiect mai târziu!)

Prin referință, după valoare?

Parametrii sunt transmisi fie prin referință, fie prin valoare. Când un parametru este transmis unei funcții sau proceduri prin referință, orice modificări aduse valorii acestuia în codul apelat sunt reflectate în valoarea inițială din programul apelant. În schimb, atunci când un parametru este transmis prin valoare, codul apelat poate schimba acea valoare, dar valoarea din programul apelant rămâne neschimbată.

Visual FoxPro interpretează codul apelat de mecanismul prin care sunt transmise parametrii. Deci, când sintaxa de apelare arată astfel:

luRetVal = CallMyFunction( parami, param2 )

Visual FoxPro tratează acest lucru ca pe un apel de funcție și transmite parametrii după valoare. Totuși, dacă același cod este numit astfel:

DO CallMyFunction WITH param1, param2

apoi Visual FoxPro tratează acest lucru ca pe un apel de procedură și transmite parametrii prin referință. Vechea regulă de codare conform căreia „Funcția trebuie să returneze întotdeauna o valoare” nu este cu adevărat adevărată în Visual FoxPro, dar are sens atunci când este luată în considerare sintaxa de apelare.

Puteți modifica acest comportament implicit în două moduri. O modalitate este de a:

SETĂ UDFPARMS LA REFERINȚĂ sau SETĂ UDFPARMS LA VALOARE

Cu toate acestea, nu considerăm că aceasta este o idee bună, deoarece afectează modul în care toate funcțiile din întreaga aplicație gestionează parametrii pe care îi transmit. (Nu este niciodată o idee bună să folosiți o soluție globală pentru a rezolva o problemă locală). În acest caz, există o soluție simplă, deoarece parametrii pot fi trecuți prin valoare în mod explicit doar prin includerea lor în paranteze. Prin urmare:

DO CallMyFunction WITH (param1), (param2)

transmite parametrii după valoare, chiar dacă sintaxa utilizată ar determina, în mod normal, trecerea lor prin referință. Pentru a transmite parametrii în mod explicit prin referință, pur și simplu prefațați parametrul cu simbolul. (Apropo, aceasta este singura modalitate de a trece un întreg tablou unei proceduri, funcție sau metodă). Deci, am putea, de asemenea, să facem apelul nostru de funcție și să transmitem parametrii acesteia prin referință astfel:

luRetVal = CallMyFunction( @param1, @param2 )

De unde știu ce a fost trecut?

Există două moduri prin care o funcție poate determina câți parametri i-au fost transferați. Funcția PARAMETERSÇ) returnează numărul de parametri care au fost trecuți la cel mai recent

numită funcţie sau procedură. Acest lucru poate da rezultate neașteptate, deoarece este resetat de fiecare dată când este apelată o funcție sau o procedură. Cel mai important, este resetat și de funcții care nu sunt apelate explicit, cum ar fi rutinele ONKEYLABEL.

O modalitate mai bună de a determina câți parametri au fost transferați unei funcții este să utilizați funcția PCOUNT(). Aceasta returnează întotdeauna numărul de parametri care au fost transferați codului care se execută în prezent. Salvați-vă multă durere și tragerea inutilă de păr folosind întotdeauna PCOUNT() pentru a determina numărul de parametri trecuți.

Cum ar trebui să-mi poziționez parametrii?

Cel mai bun sfat este că, dacă o funcție preia parametri opționali, ar trebui să îi plasați la sfârșitul listei de parametri. PCOUNT() poate fi apoi utilizat în funcție pentru a determina dacă parametrii opționali au fost sau nu trecuți, permițând funcției să ia acțiunea corespunzătoare.

Puteți profita de faptul că Visual FoxPro inițializează întotdeauna parametrii ca falși logic. Configurați funcția dvs. pentru a aștepta un fals logic ca implicit, puteți invoca funcția fără a-i transmite niciun parametru. Apoi, în acele cazuri în care doriți un comportament alternativ, invocați funcția prin transmiterea unui adevărat logic.

Cum pot returna mai multe valori dintr-o funcție?

Desigur, returnarea valorilor este pur și simplu inversul trecerii parametrilor - cu o singură înțelegere!. Deși puteți trece cu ușurință mai mulți parametri unei funcții, nu există un mecanism evident pentru returnarea mai multor valori! Comanda RETURN permite doar o singură valoare să fie transmisă înapoi programului apelant.

O soluție este să transmiteți mai multe valori ca șir delimitat prin virgulă. Acest lucru este puțin dezordonat, totuși, deoarece va trebui să convertiți valorile în format de caractere pentru a construi șirul de returnare și apoi să analizați din nou valorile individuale în codul de primire.

O altă posibilitate este să definiți toate valorile pe care doriți să le populați de funcție ca variabile private în programul apelant. Ca atare, acestea vor fi disponibile pentru orice funcție sau procedură care este apelată ulterior și pot fi populate direct. Cu toate acestea, acest lucru nu este nici specific, nici ușor de întreținut și nu este cu adevărat o soluție bună.

O posibilitate mai bună este să creați o matrice în codul de apelare pentru valorile returnate și apoi să treceți acea matrice prin referință. Funcția apelată poate apoi pur și simplu popula matricea, iar valorile vor fi disponibile și în programul apelant. Aceasta este cel puțin viabilă și a fost probabil cea mai comună metodă de a gestiona problema înainte de introducerea Visual FoxPro.

Încă o dată, Visual FoxPro a făcut viața mult mai ușoară. Returnarea mai multor valori dintr-un UDF este ușoară dacă creați și utilizați o clasă de parametri. Al nostru se bazează pe clasa de bază Line și se numește xParameters. Îl puteți găsi în biblioteca de clase CH02.VCX. Tot ce are nevoie este o proprietate personalizată a matricei, aParameters, pentru a păstra valorile returnate și această linie de cod în INIT():

LPARAMETERS taArray

ACOPY(taArray, This.aParameters)

Funcția definită de utilizator își poate completa pur și simplu propria matrice locală cu valorile de care are nevoie pentru a le returna și poate crea obiectul parametru din mers - și poate popula proprietatea matricei a obiectului cu o singură linie de cod:

RETURN CREATOBJECT('xParameters', @laArray )

Cum rămâne cu utilizarea parametrilor numiți?

Obiectul parametru discutat mai sus transmite parametrii după poziție, aproape în același mod ca și Visual FoxPro. Deși Visual FoxPro nu acceptă de fapt conceptul de parametri numiți, puteți, în versiunea 6.0, să utilizați metoda AddProperty() pentru a adăuga parametri numiți obiectului dvs. prin crearea unei proprietăți pentru fiecare parametru sau valoare pe care doriți să o transferați

Chiar și atunci când utilizați această abordare, nu este nevoie să creați o clasă specială pentru obiectul parametru. Poate fi creat din mers folosind o clasă de bază ușoară, cum ar fi Line sau Separator, după cum arată următorul fragment de cod:

LOCAL oParam

oParam = CREATEOBJECT( 'linie' )

CU oParam

.AddProperty( „Nume”, „Christine Johannson”)

.AddProperty( „Vârsta”, 34 )

.AddProperty( „Sex”, „Femeie”)

SE TERMINA CU

RETURN oParam

Pentru a prelua valori în acest mod, codul dvs. de apel ar atribui pur și simplu valoarea de returnare a funcției apelate unei referințe de obiect și ar citi proprietățile acesteia la nivel local:

LOCAL oRetVal

oRetVal = CallMyFunction()

lcName = oRetVal. Nume

lnAge = oRetVal.Age

lcSex = oRetVal.Sex

Dintre toate posibilitățile discutate până acum, aceasta ne place cel mai bine!

Transmiterea parametrilor opțional

Există un avantaj secundar important pentru capacitatea de a utiliza parametrii numiți. Acest lucru devine deosebit de important atunci când o funcție acceptă un număr mare de parametri, dintre care mulți sunt opționali. De exemplu, o funcție de setare a fonturilor poate avea mulți parametri (nume, dimensiune, bold, italic, subliniat, barat și așa mai departe). O simplă verificare pentru:

PEMSTATUS(toParameterObject, 'FontName', 5 )

determină fără ambiguitate dacă a fost trecut sau nu un anumit parametru. Această abordare elimină sarcina obositoare de a număra virgulele în programul de apelare (precum și necesitatea de a reține

ordinea specifică în care parametrii sunt așteptați de funcția apelată). Funcția timp scurs de mai jos arată modul în care un obiect care utilizează parametri numiți poate fi utilizat pentru a returna mai multe valori.
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Funcții de dată și oră

Visual FoxPro are câteva funcții dandy la îndemână, încorporate pentru manipularea datelor. Funcțiile de mai jos ilustrează modul în care pot fi utilizate pentru a îndeplini câteva dintre cele mai frecvente sarcini necesare atunci când vă ocupați de date în aplicațiile dvs.

Timpul scurs

Pur și simplu scăderea unei expresii DateTime de la alta vă oferă timpul scurs - acest lucru este bine. Din păcate, Visual FoxPro vă oferă acest rezultat ca număr de secunde între cele două - acest lucru este rău. Această valoare este rareori utilă direct! Puteți utiliza acest mic set de funcții, care se bazează pe operatorul Modulus (%), pentru a calcula componentele timpului scurs în zile, ore, minute și secunde.

FUNCȚIA GetDays( tnElapsedSeconds )

RETURN INT(tnElapsedSeconds / 86400)

FUNCȚIA GetHours(tnElapsedSeconds)

RETURN INT(( tnElapsedSeconds % 86400 ) / 3600 )

FUNCȚIA GetMinutes( tnElapsedSeconds )

RETURN INT(( tnElapsedSeconds % 3600 ) / 60 )

FUNCȚIA GetSeconds( tnElapsedSeconds )

RETURN INT( tnElapsedSeconds % 60 )

Desigur, există mai multe moduri de a jupui vulpea. De asemenea, puteți utiliza o singură funcție pentru a returna o matrice care conține timpul scurs pozițional, cu zile ca prim element până la secunde ca al patrulea, astfel:

FUNCȚIA GetElapsedTime(tnElapsedSeconds)

LOCAL laTime[4]

laTime[1] = INT( tnElapsedSeconds / 86400 )

laTime[2] = INT(( tnElapsedSeconds % 86400 ) / 3600 )

laTime[3] = INT(( tnElapsedSeconds % 3600 ) / 60 )

laTime[4] = INT( tnElapsedSeconds % 60 )

RETURN CREATEOBJECT('xParameters', @laTime )

Dacă preferați parametrii numiți decât varietatea pozițională, următorul cod îndeplinește sarcina:

FUNCȚIA GetElapsedTime(tnElapsedSeconds)

LOCAL loObject

loObject = CREATEOBJECT('Linie')

CU loObject

.AddProperty( 'nZile', INT( tnElapsedSeconds / 86400 ) )

.AddProperty( 'nOre', INT(( tnElapsedSeconds % 86400 ) / 3600 ) )

.AddProperty( 'nMins', INT(( tnElapsedSeconds % 3600 ) / 60 ) )

.AddProperty( 'nSecs', INT( tnElapsedSeconds % 60 ) )

SE TERMINA CU

RETURN loObject

Alternativ, dacă aveți nevoie doar de un șir care conține timpul scurs în cuvinte, îl puteți reduce la o singură linie de cod!

FUNCȚIA GetElapsedTime(tnElapsedSeconds)

RETURN PADL( INT( tnElapsedSeconds / 86400 ), 3 ) + ' Zile

+ PADL( INT(( tnElapsedSeconds % 86400 ) / 3600 ), 2, '0' ) + ' Hrs

+

PADL (

INT(( tnElapsedSeconds % 3600 ) / 60 ),

2, '0')+' Min ';

+ PADL( INT( tnElapsedSeconds % 60 ), 2, '0' ) + ' Sec

Data în cuvinte

Convertirea unei valori din formatul de dată în text poate fi o afacere dificilă, mai ales atunci când scrieți aplicații internaționale. Visual FoxPro face această sarcină mult mai ușoară cu funcțiile sale native MDY(), CMONTH(), CDOW(), MONTH(), DAY() și YEAR(), pentru a numi doar câteva. Versiunea 6.0, cu capacitatea sa de a folosi date stricte, face această sarcină și mai ușoară. Următoarea funcție oferă un exemplu de utilizare a acestor funcții.

FUNCȚIA DateInWords( tdDate )

RETURN CDOW( tdDate ) + ', ' + MDY( tdDate )

Cu toate acestea, funcția enumerată mai sus nu va atașa sufixul ordinal la porțiunea de zi a datei. Dacă aplicația dvs. necesită aceste sufixe atunci când formatați data în cuvinte, utilizați forma mai lungă a funcției enumerate mai jos. Puteți chiar să extrageți porțiunea care calculează sufixul și să o plasați într-o funcție numită MakeOrdinal. Acesta poate fi apoi invocat oricând trebuie să formatați un anumit număr n ca al n-lea.

FUNCȚIA DateInWords( tdDate )

LOCAL LnDay, lnNdx, lcSuffix[31]

*** Inițializați sufixul pentru zi

lnDay = DAY( tdDate )

lnNdx = lnDay % 10

DACA NU INTRE( lnNdx, 1, 3 )

lcSuffix = 'th'

ALTE

DACĂ INT( lnDay / 10 ) = 1

lcSuffix = 'th'

ALTE

lcSuffix = SUBSTR( 'stndrd', ( 2 * lnNdx ) - 1, 2 )

ENDIF

ENDIF

RETURN CDOW( tdDate ) + ', ' + CMONTH( tdDate ) + ;

' ' + ALLTRIM( STR( lnDay )) + lcSufix + ;

', ' + ALLTRIM( STR( YEAR( tdDate )))

Calcularea vârstei

Calcularea vârstei este chiar mai dificilă decât calcularea timpului scurs. Acest lucru se datorează faptului că lunile nu conțin același număr de zile și fiecare al patrulea an este un an bisect. Funcția de mai jos calculează vârsta la o dată dată și returnează valoarea ca șir formatat care conține numărul de ani și luni. Aceasta

poate fi modificat cu ușurință pentru a returna valorile dintr-un obiect cu parametri precum funcția ElapsedTime() enumerată mai sus.

FUNCȚIE CalcAge (tdDob, tdBaseDate)

*** Data de bază implicită la Azi dacă este gol

IF TYPE( „tdBaseDate” ) # „D” SAU EMPTY(tdBaseDate)

tdBaseDate = DATA()

ENDIF

LOCAL lnYrs, lnMth, lcRetVal, lnBaseYear, lnBaseMnth

lnYrs = YEAR( tdBaseDate ) - YEAR(tdDob )

*** Calculați ziua de naștere din acest an

ldCurBdy = CTOD('A' + STR( YEAR( tdBaseDate )) + '-' + ;

PADL( LUNA( tdDob ), 2, '0' ) + '-' + ;

PADL( DAY( tdDob ), 2, '0'))

*** Calculați vârsta

IF ldCurBdy > tdBaseDate

lnYrs = lnYrs - 1

lnMth = 12 - (MONTH( tdBaseDate ) - MONTH( tdDob )) - 1

ALTE

lnMth = MONTH( tdBaseDate ) - MONTH( tdDob )

ENDIF

*** Formatează șirul de ieșire

lcRetVal = PADL( lnYrs, 4 ) + " Ani, " + PADL( lnMth, 2, '0' ) + " Luna" + ;

IIF(lnMth = 1, "", "s" )

RETURN ALLTRIM( lcRetVal )

Care este a doua zi de marți din octombrie 2000?

Aceasta este o mică funcție la îndemână care poate fi folosită pentru a calcula data exactă a sărbătorilor într-un anumit an. De exemplu, în Statele Unite, Ziua Recunoștinței cade întotdeauna în a patra joi din noiembrie. Un alt exemplu pe care l-am întâlnit recent a fost că anul universitar pentru școli și universități începe întotdeauna în prima zi de luni a lunii august. Capacitatea de a calcula datele reale pentru astfel de zile definite este esențială în orice aplicație care necesită planificarea unui program anual.

**************************************************** ********************

* 	Program. nthSomeDayOfMonth

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Returnează data unui anumit tip de zi; de exemplu, cel

* 	..........:a doua zi de marți a lunii noiembrie a anului 2001

* 	...........: nthSomedayOfMonth( 4, 3, 7, 2000 ) returnează data de

* 	...........: a 3-a miercuri din iulie a anului 2000

* 	Parametri.: tnDayNum: Ziua numărul 1=duminică 7=sâmbătă

* 	..........:tnWhich : Pe care să găsești; 1, 2 etc.

* 	...........: Dacă tnwhich > numărul acestui gen de zi

* 	...........: în lună se returnează ultimul

* 	..........:tnMonth : Month Numărul în care se află ziua

* ...........: 	tnYear : Anul în care se află ziua

**************************************************** ********************

FUNCȚIA nthSomedayOfMonth( tnDayNum, tnWhich, tnMonth, tnYear )

LOCAL ldDate, lnCnt

*** Începe din prima zi a lunii specificate

ldDate = DATA( tnYear, tnMonth, 01 )

*** Găsiți primul din ziua specificată a săptămânii

DO WHILE DOW( ldDate ) # tnDayNum

ldDate = ldDate + 1

ENDDO

*** Găsiți unul dintre acestea specificate... de exemplu, al doilea, al treilea sau ultimul

IF tnWhich > 1

lnCnt = 1

FĂ CÂND lnCnt < tnWhich

lnCnt = lnCnt + 1

*** Înainte cu o săptămână pentru a obține următoarea dintre acestea în luna ldDate = ldDate + 7

*** Suntem încă în luna corectă?

IF MONTH( ldDate ) # tnMonth

*** Dacă nu, sări înapoi la ultimul dintre acestea pe care l-am găsit și ieși

ldDate = ldDate - 7

IEȘIRE

ENDIF

ENDDO

ENDIF

RETURN ldDate

Stabilirea unui program de plată

O altă problemă interesantă este cea a stabilirii unui program lunar. Luați, de exemplu, un program de plăți lunare care trebuie încasate prin debitare directă a contului curent al unui debitor. Evident, aceste plăți nu pot fi încasate în zilele de duminică sau de sărbători. De asemenea, acestea nu pot fi colectate mai devreme de ziua specificată când programul este stabilit pentru prima dată. Acest lucru ridică unele probleme interesante dacă data inițială de semințe pentru program este între 28 și 31 ale lunii. Deci, în acest caz, simpla folosire a funcției GOMONTH() poate returna o dată inacceptabilă.

Această funcție se ocupă de weekenduri, sărbători și GOMONTH() și presupune că ați creat tabelul de vacanță cu două coloane: una pentru dată și una pentru numele sărbătorii. De asemenea, este de dorit un index privind data sărbătorii. De asemenea, tine cont de faptul ca pentru a fi utila, acest tabel de sarbatori trebuie sa contina, cel putin, sarbatorile atat pentru anul acesta cat si pentru anul viitor.

FUNCȚIE MonthlySchedule ( tdStartDate, tnNumberOfMonths )

LOCAL laDates[1], lnCnt, ldDate, llOK, llUsed

*** Asigurați-vă că avem biblioteca de clasă încărcată

IF 'CH02' $ SET( 'CLASSLIB' )

*** Nu faceți nimic... biblioteca de clasă este încărcată

ALTE

SETĂ CLASSLIB LA ADITIVUL CH02

ENDIF

*** Asigurați-vă că avem disponibil tabelul Sărbătorilor

DACĂ !FOLOSIT( „Sărbători”)

UTILIZAȚI Sărbători în 0

llUsed = .F.

ALTE

llUsed = .T.

ENDIF

SELECTARE Sărbători

SETĂ COMANDA LA dHoliday

FOR lnCnt = 1 TO tnNumberOfMonths

*** dorim să returnăm data trecută ca dată[1]

DACĂ LnCnt > 1

ldDate = GOMONTH( tdStartDate, lnCnt-1 )

ALTE

ldDate = tdStartDate

ENDIF

*** Acum trebuie să verificăm pentru a ne asigura că GoMonth nu ne-a returnat o zi *** care este mai devreme decât data de lansare... nu se poate face o debitare directă ÎNAINTE de *** data specificată, adică, data de 28 a lunii

DACĂ ZI (tdStartDate) > 28

DACĂ ÎNTRE( DAY( ldDate ), 28, DAY( tdStartDate ) - 1 )

ldDate = ldDate + 1

ENDIF

ENDIF

llOK = .F.

FĂ CÂND !llOK

*** Dacă data curentă este sâmbătă, mergeți la luni

DACĂ DOW(ldDate) = 7

ldDate = ldDate + 2

ALTE

*** Dacă data curentă este o duminică, mergeți la luni

DACĂ DOW(ldDate) = 1

ldDate = ldDate + 1

ENDIF

ENDIF

*** OK, acum verificați sărbătorile

DACĂ !SEEK( ldDate, „Sărbătoare”, „dSărbătoare” )

llOK = .T.

ALTE

ldDate = ldDate + 1

ENDIF

ENDDO

DIMENSION laDates[lnCnt]

laDates[lnCnt]

ldDate

ENDFOR

IF !llUsed

UTILIZARE ÎN Sărbători

ENDIF

RETURN CREATEOBJECT('xParameters', @laDates )

La ce dată sunt zece zile lucrătoare de astăzi?

O problemă oarecum similară este modul în care se calculează o dată care este un număr specificat de zile lucrătoare de la o dată dată. Ca și în exemplul anterior, aceasta presupune existența unui tabel de vacanță care este atât specific regiunii, cât și aplicației.

FUNCȚIE Business Days ( tdStartDate, tnNumberOfDays )

LOCAL LnCnt, ldDate, llOK, llUsed

*** Asigurați-vă că avem disponibil tabelul Sărbătorilor

DACĂ !FOLOSIT( „Sărbători” )

UTILIZAȚI Sărbători în 0

llUsed = .F.

ALTE

llUsed = .T.

ENDIF

SELECTARE Sărbători

SETĂ COMANDA LA dHoliday

ldDate = tdStartDate

PENTRU lnCnt = 1 LA tnNumberOfDays

ldDate = ldDate + 1

llOK = .F.

FĂ CÂND !llOK

*** Dacă data curentă este sâmbătă, mergeți la luni

DACĂ DOW(ldDate) = 7

ldDate = ldDate + 2

ALTE

*** Dacă data curentă este o duminică, mergeți la luni

DACĂ DOW(ldDate) = 1

ldDate = ldDate + 1

ENDIF

ENDIF

*** OK, acum verificați sărbătorile

DACĂ !SEEK( ldDate, „Sărbătoare”, „dSărbătoare” )

llOK = .T.

ALTE

ldDate = ldDate + 1

ENDIF

ENDDO

ENDFOR

IF !llUsed

UTILIZARE ÎN Sărbători

ENDIF

RETURN ldDate

Am inteles! Format strict de dată și vizualizări parametrizate

Formatul StrictDate de la Visual FoxPro este deosebit de reconfortant cu spectrul bug-ului mileniului care se profilează în fața noastră. Cel puțin așa este așa cum scriem asta. Există totuși o mică eroare de care ar trebui să fii conștient. Dacă ați SETAT STRICTDATE LA 2 și încercați să deschideți o vizualizare parametrizată care ia o dată ca parametru, veți avea probleme. Dacă parametrul de vizualizare nu este definit sau nu este în domeniul de aplicare atunci când deschideți sau reinterogați vizualizarea, caseta de dialog prietenoasă care solicită parametrul de vizualizare nu va accepta nimic pe care îl introduceți. Va continua să spună că ați introdus o constantă de dată/date și oră ambiguă.

Soluția este să vă asigurați că parametrul de vizualizare este definit și în domeniul de aplicare înainte de a încerca să deschideți sau să interogați din nou vizualizarea. Aceasta înseamnă că, dacă vizualizarea dvs. face parte din mediul de date al unui formular, proprietatea sa NoDataOnLoad trebuie setată pentru a evita primirea dialogului pe măsură ce formularul se încarcă.

Cealaltă soluție, setarea StrictDate la 0 și apoi înapoi la 2, nu este recomandată. După cum am menționat deja, folosirea unei soluții globale pentru o problemă locală este un pic ca a lovi muștele cu un baros.
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Lucrul cu numerele

Calculele matematice au fost gestionate destul de bine încă din zilele lui Eniac și Maniac, cu excepția erorii notabile din co-procesorul de matematică Pentium. Cele mai frecvente probleme apar deoarece multe calcule produc rezultate iraționale, cum ar fi numere care continuă pentru un număr infinit de zecimale. Erorile de rotunjire sunt imposibil de evitat deoarece calculul necesită ca aceste numere să fie reprezentate într-o formă finită. Studiul analizei numerice se ocupă de modul de minimizare a acestor erori prin modificarea ordinii în care sunt efectuate operațiile matematice precum și furnizarea de metode precum metoda trapezoidală pentru calcularea ariei de sub curbă. O discuție despre acest subiect depășește domeniul de aplicare al acestei cărți, dar vă putem oferi câteva sfaturi și probleme de care să aveți grijă atunci când lucrați cu numere în aplicația dvs.

Conversia numerelor în șiruri

Convertirea numerelor întregi în șiruri de caractere este destul de simplă. ALLTRIM( STR( lnSomeNumber ) ) va gestiona conversia dacă întregul conține zece cifre sau mai puțin. Dacă întregul conține mai mult de zece cifre, această funcție va produce un șir în format de notație științifică, cu excepția cazului în care specificați lungimea rezultatului șirului ca al doilea parametru. Când convertiți valori numerice care conțin zecimale sau valori valutare, probabil că este mai bine să utilizați o altă funcție. Deși poate fi realizat folosind funcția STR(), este dificil să scrieți o rutină de conversie generică. Pentru a converti întregul număr trebuie să specificați atât lungimea totală a numărului (inclusiv virgulă zecimală), cât și numărul de cifre din dreapta virgulei zecimale. Astfel, STR(1234.5678) va produce „1235” ca rezultat, iar pentru a obține conversia corectă trebuie să specificați STR(1234.5678, 9, 4).

În Visual FoxPro 6.0, funcția Transform() a fost extinsă astfel încât, atunci când este apelată fără parametri de formatare, returnează pur și simplu valoarea transmisă ca șir de caractere echivalent. Astfel transform(1234.5678) va returna coiTect „1234.5678”.

În toate versiunile de Visual FoxPro puteți utiliza alltrim( padl ( lnsomeNumber, 32 ) ) pentru a obține același rezultat (cu condiția ca lungimea totală a InSomeNumber să fie mai mică de treizeci și două de cifre).

Am inteles! calcule care implică bani

Acesta poate mușca dacă nu ești atent. Încercați acest lucru în fereastra de comandă și veți vedea la ce ne referim.

? ( 1000 USD / 3 )

returnează rezultatul așteptat de 333,3333, deoarece valorile valutare sunt întotdeauna calculate cu o precizie de patru zecimale. In orice caz,

( 1000 USD * ( 1/3 ) )

returnează 333.3000, ceea ce nu este un rezultat foarte precis! Mai ales când luați în considerare rezultatul calculului numeric echivalent:

SETATE DECIMALE LA 4

? ( 1000 * ( 1/3 ) )

returnează 333,3333. Precizia reală a rezultatului afișat depinde de setarea SET DECIMALS, deși rezultatul este de fapt calculat la 8 locuri în mod implicit.

Morala acestei povești este că valorile valutare ar trebui întotdeauna convertite în cifre înainte de a le folosi în operațiuni aritmetice. Funcțiile MTON() și NTOM() sunt esențiale în acest scenariu, deși aveți grijă la rezultate neașteptate dacă nu convertiți în ambele sensuri!

? ( MTON( 1000 USD ) * ( 1/3 ) )

afișează 333.333333 chiar și cu zecimale setate la 2. În timp ce

? NTOM( ( MTON( $ 1000 ) * ( 1/3 ) ) )

în sfârșit obține rezultatul așteptat de 333,3333.
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Funcții șiruri

Visual FoxPro are mai multe funcții native de manipulare a șirurilor pentru a gestiona aproape tot ce ai putea avea nevoie vreodată. ALLTRIM() pentru a elimina spațiile de început și de final, PADL() și PADR() la pad-ul din stânga și din dreapta și STRTRAN() și CHRTRAN() pentru a înlocui caracterele individuale dintr-un șir. Dar știați că puteți utiliza această linie de cod:

cStringl - cString2 - cString3

pentru a realiza același lucru ca acesta?

RTRIM(cStringl) + RTRIM(cString2) + RTRIM(cString3)

Am inteles! concatenare a corzilor

Chiar dacă tabelele din aplicația dvs. nu permit valori nule, este posibil să aveți nevoie totuși să vă ocupați de ele. Foarte des, instrucțiunile SQL care utilizează îmbinări exterioare au ca rezultat una sau mai multe coloane care conțin valori nule. Acest lucru poate fi deranjant în cazurile în care este posibil să doriți să afișați o valoare concatenată dintr-un set de rezultate, de exemplu, într-o listă derulantă. Încercați acest lucru în fereastra de comandă:

cl = „Yada Yada Yada”

c2 = .NULL.

? c1 + c2

După cum v-ați putea aștepta, Visual FoxPro se plânge de nepotrivirea tipului de operator/operand. Dacă, totuși, faci asta în schimb:

? c1 + ALLTRIM( c2 )

vei vedea .null. afișat pe ecranul Visual FoxPro.

Nicio eroare, doar .NULL. Dacă nu țineți cont de valorile nule utilizând NVL() pentru a le capta, este posibil să găsiți acest comportament puțin dificil de depanat atunci când apare în aplicația dvs. Cu siguranță am făcut-o prima dată când am întâlnit acest comportament!

Conversia între șiruri și date

Următoarele sunt exemple de funcții pe care Visual FoxPro nu le are, dar în opinia noastră cu siguranță ar trebui să le aibă. Acestea le păstrăm în fișierul nostru general cu proceduri universale, deoarece le folosim atât de des.

Casetele Combo și Listă își stochează listele interne ca valori de șir. Deci, atunci când trebuie să le utilizați pentru a actualiza sau a căuta valori ale altor tipuri de date, trebuie să convertiți aceste șiruri la tipul de date adecvat înainte de a le putea folosi. Prima dintre aceste funcții este folosită pentru a face exact asta:

FUNCȚIA Str2Exp( tcExp, tcType )

*** Convertiți șirul transmis în tipul de date transmis

LOCAL luRetVal, lcType

*** Eliminați ghilimele duble (dacă există)

tcExp = STRTRAN( ALLTRIM( tcExp ), CHR( 34 ), "" )

*** Dacă nu s-a transmis niciun tip - mapați la tipul expresiei

lcType = IIF( TYPE( 'tcType' ) = 'C', UPPER(ALLTRIM ( tcType )), TYPE (tcExp ) )

*** Convertiți de la caracter la tipul corect

FACE CAZ

CASE INLIST( IcType, 'I', 'N' ) AND ;

INT( VAL( tcExp ) ) == VAL( tcExp ) && întreg

luRetVal = INT( VAL( tcExp ) )

CASE INLIST( IcType, 'N', 'Y', 'B' ) && Numeric sau Currency

luRetVal = VAL( tcExp )

CASE INLIST( lcType, 'C', 'M' ) && Caracter sau notă

luRetVal = tcExp

CASE lcType = 'L' && logic

luRetVal = IIF( !EMPTY( tcExp ), .T., .F.)

CASE lcType = 'D' && Data

luRetVal = CTOD(tcExp)

CASE lcType = 'T' && DateTime

luRetVal = CTOT( tcExp )

IN CAZ CONTRAR

*** Nu există altfel decât dacă, desigur, adaugă Visual FoxPro

*** un nou tip de date. În acest caz, funcția trebuie modificată

ENDCASE

*** Valoarea returnată ca tip de date

RETURN luRetVal

Dacă scrieți aplicații client/server, știți deja că trebuie să convertiți toate expresiile în șiruri de caractere înainte de a le utiliza într-un SQLEXEC(). Chiar dacă nu faceți dezvoltare client/server, veți avea nevoie de această funcționalitate pentru a construi orice fel de SQL din mers.

Următoarea funcție nu numai că convertește parametrul transmis într-o valoare de caracter, ci și împachetează rezultatul în ghilimele, acolo unde este cazul. Acest lucru este util în special atunci când invocați funcția de la un generator SQL onthefly. Este și mai ușor în Visual FoxPro 6.0 deoarece puteți utiliza funcția TRANSFORM fără un șir de format pentru a converti primul argument în caracter.

TRANSFORM( 1234.56 ) produce același rezultat ca ALLTRIM( PADL( 1234.56, 32 ) ).

FUNCȚIA Exp2Str( tuExp, tcType )

*** Convertiți expresia transmisă în șir

LOCAL lcRetVal, lcType

*** Dacă nu s-a transmis niciun tip - mapați la tipul expresiei

lcType=IIF( TYPE('tcType' )='C', UPPER( ALLTRIM(tcType) ), TYPE('tuExp' ) )

*** Convertiți din tip în caracter

FACE CAZ

CASE INLIST( lcType, 'I', 'N' ) AND INT( tuExp ) = tuExp && Integer

lcRetVal = ALLTRIM( STR( tuExp, 16, 0 ) )

CASE INLIST( lcType, 'N', 'Y', 'B' ) && Numeric sau Currency

lcRetVal = ALLTRIM( PADL( tuExp, 32 ) )

CASE lcType = „C” && Caracter

lcRetVal = '"' + ALLTRIM( tuExp ) + '"'

CASE lcType = 'L' && logic

lcRetVal = IIF( !EMPTY( tuExp ), '.T.', '.F.')

CASE IcType = 'D' && Data

lcRetVal = '"' + ALLTRIM( DTOC( tuExp ) ) + '"'

CASE lcType = 'T' && DateTime

lcRetVal = '"' + ALLTRIM( TTOC( tuExp ) ) + '"'

IN CAZ CONTRAR

*** Nu există altfel decât dacă, desigur, adaugă Visual FoxPro

*** un nou tip de date. În acest caz, funcția trebuie modificată ENDCASE

*** Valoarea returnată ca caracter

RETURN lcRetVal
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Alte funcții utile

Există câteva alte funcții generice care pot locui în fișierul dumneavoastră de procedură generală sau în clasa de procedură de bază. Un exemplu evident este funcția SetPath() (prezentată în Capitolul Unu). Găsim următoarele funcții deosebit de utile și sperăm că și dumneavoastră.

Cum determin dacă există o etichetă?

Nu ar fi frumos dacă Visual FoxPro ar avea o funcție nativă care să returneze adevărată dacă ar exista o etichetă? Acest lucru ar fi deosebit de util, de exemplu, atunci când se creează o clasă de grilă personalizată care permite utilizatorului să facă clic pe antetul unei coloane pentru a sorta grila după eticheta de pe acea coloană. De asemenea, ar fi util să se testeze existența unui index dacă acesta trebuie creat programatic. Acest cod oferă această funcționalitate.

FUNCȚIA ISTAG( tcTagName, tcTable )

LOCAL lnCnt, llRetVal, InSelect

IF TYPE( 'tcTagName' ) # 'C'

*** Eroare - trebuie să treacă un Nume de etichetă

EROARE „9000: Trebuie să treacă un nume de etichetă atunci când apelați ISTAG()”

RETURNARE .F.

ENDIF

*** Salvați numărul zonei de lucru

lnSelect = SELECT ()

IF TYPE( 'tcTable' ) = 'C' AND ! EMPTY( tcTable )

*** Dacă a fost specificat un tabel, selectați-l

SELECTează lcTable

ENDIF

*** Verificați etichetele

FOR lnCnt = 1 TO TAGCOUNT()

IF UPPER(ALLTRIM (tcTagName) ) și UPPER( ALLTRIM( TAG(lnCnt ) ) )

llRetVal = .T.

IEȘIRE

ENDIF

URMĂTORUL

*** Restaurați zona de lucru

SELECTARE (lnSelect)

*** Reveniți dacă eticheta a fost găsită

RETURN llRetVal

Apropo, observați utilizarea comenzii de eroare în această funcție. În loc să afișeze pur și simplu un mesaj când un parametru nu reușește validarea, această funcție generează o eroare de aplicație care poate fi prinsă de un handler de erori, la fel ca o eroare normală Visual FoxPro.

Cum pot determina dacă un șir conține cel puțin un caracter alfabetic?

Visual FoxPro ISALPHA() returnează .T dacă șirul transmis începe cu o literă. În mod similar, ISDIGIT() va face același lucru dacă șirul începe cu un număr. Dar ce se întâmplă dacă trebuie să știi dacă șirul conține caractere alfabetice? Un astfel de cod ar funcționa, dar este lent și voluminos:

FUNCȚIA ContainsAlpha(tcString)

LOCAL lnChar, llRetVal

llRetVal = .F.

*** Buclă prin șir și testează fiecare caracter

FOR lnChar = 1 TO LEN( tcString )

IF ISALPHA( SUBSTR( tcString, lnChar, 1 )

llRetVal = .T.

IEȘIRE

ENDIF

ENDFOR

RETURN llRetVal

Totuși, de ce să scrieți zece linii de cod când două vor face aceeași treabă?

FUNCȚIA ContainsAlpha(tcString)

RETURN LEN( CHRTRAN( UPPER( tcString ), "ABCDEFGHIJKLMNOPQRSTUVWXYZ", "" ) );

# LEN( tcString )

Evident, o metodologie similară poate fi folosită pentru a determina dacă un șir conține cifre. Cu toate acestea, refuzăm să insultăm inteligența cititorilor noștri listând-o aici. La urma urmei, ați fost suficient de deștepți pentru a cumpăra această carte, nu-i așa?

Cum se transformă numere în cuvinte

O problemă comună este aceea de a converti numerele în șiruri de caractere, pentru tipărirea cecurilor sau ca confirmare a unei facturi sau a unui total de comandă. Au fost multe soluții propuse pentru aceasta de-a lungul anilor, dar aceasta ne place în continuare cel mai bine deoarece se ocupă de numere mari, numere negative și adoptă o abordare inovatoare și a zecimalelor.

**************************************************** ********************

* 	Program. ...: NumToStr

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Convertiți numărul într-un șir de text

* 	Note......: Se ocupă de numere de până la 99.999.999 și va găzdui

* 	..........:numere negative. Decimalele sunt rotunjite la două locuri

* 	..........:Și returnat ca „și xxxx sutimi”

**************************************************** **********************

FUNCȚIE NumToStr

LPARAMETERS tnvalue

LOCAL lnHund, lnThou, lnHTho, lnMill, lnInt, lnDec

LOCAL llDecFlag, llHFlag, llTFlag, llMFlag, llNegFlag

LOCAL lcRetVal

*** Evaluați parametrii

FACE CAZ

CAZ TYPE('tnValue') # 'N'

ÎNTOARCERE('')

CASE tnvalue = 0

RETURN „Zero”

CASE tnvalue < 0

*** Setați indicatorul negativ și convertiți valoarea în pozitiv llNegFlag = .T.

tnvalue = ABS(tnvalue)

IN CAZ CONTRAR

llNegFlag = .F.

ENDCASE

*** Inițializați variabile

MAGAZIN .F. TO llHFlag,llTFlag,llMFlag

STORE 0 TO lnHund, lnThou, lnMill

STOCAZĂ „” LA lcRetVal

*** Obțineți porțiunea Integer

lnInt = INT(tnvalue)

*** Verificați dacă există zecimale

DACĂ MOD(tnValue, 1) # 0

lnDec = ROUND(MOD(tnvalue,1),2)

llDecFlag = .T.

ALTE

llDecFlag = .F.

ENDIF

*** Faceți mai întâi porțiunea întregului

FĂ CÂND .T.

FACE CAZ

CAZ lnInt < 100 && TENS

DACĂ GOL (lcRetVal)

lcRetVal = lcRetVal + ALLTRIM(con_tens(lnInt))

ALTE

IF RIGHT(lcRetVal,5)#" și "

lcRetVal = lcRetVal+' și '

ENDIF

lcRetVal = lcRetVal + ALLTRIM(con_tens(lnInt))

ENDIF

CAZ lnInt < 1000 && SUTE

lnHund = INT(lnInt/100)

lnInt = lnInt - (lnHund*100)

lcRetVal = lcRetVal + ALLTRIM(con_tens(lnHund)) + „Sută”

DACĂ lnInt # 0

lcRetVal = lcRetVal+" și "

BUCLĂ

ENDIF

CAZ lnInt < 100000 && MII

InThou = INT(lnInt/1000)

InInt = InInt - (lnThou*1000)

lcRetVal = lcRetVal + ALLTRIM(con_tens(lnThou)) + „Mie”

DACĂ lnInt # 0

lcRetVal = lcRetVal + " "

BUCLĂ

ENDIF

CAZ lnInt < 1000000 && Sute de mii

lnHTho = INT(lnInt/100000)

lnInt = lnInt - (lnHTho * 100000)

lcRetVal = 	lcRetVal+ALLTRIM(con_tens(lnHTho)) + „Sută”
DACĂ lnInt # 	0		
lcRetVal = 	lcRetVal+" și "
BUCLĂ			
ALTE			
lcRetVal = 	lcRetVal+"Mie"

ENDIF

CAZ lnInt < 100000000 && Milioane

lnMill = INT(lnInt/1000000)

lnInt = lnInt - (lnMill * 1000000)

lcRetVal = lcRetVal + ALLTRIM(con_tens(lnMill)) + " Milion"

DACĂ lnInt # 0

lcRetVal = lcRetVal + ", "

BUCLĂ

ENDIF

ENDCASE

IEȘIRE

ENDDO

*** Acum gestionați orice zecimală

IF llDecFlag

lnDec = lnDec * 100

lcRetVal = lcRetVal + " și " + ALLTRIM(con_tens(lnDec)) + 'Sutimi' ENDIF

*** În cele din urmă, tratează steagul negativ

IF llNegFlag

lcRetVal = "[MINUS " + ALLTRIM(lcRetVal) + "]"

ENDIF

*** Returnează șirul terminat

RETURN lcRetVal

************************************************

*** Gestionați conversia TENS

************************************************

FUNCȚIA conține

LPARAMETRI tndvalue

LOCAL lcStrVal, lcStrTeen

STORE '' LA lcStrVal,lcStrTeen

FACE CAZ

CAZ tnDValue < 20

RETURN(con_adolescenți(tnDValue))

CAZ tnDValue < 30 lcStrVal = „Douăzeci” tnDValue = tnDValue - 20

CAZ tnDValue < 40

lcStrVal = „Treizeci” tnDValue = tnDValue - 30

CAZ tnDValue < 50

lcStrVal = „Patruzeci” tnDValue = tnDValue - 40

CAZ tnDValue < 60

lcStrVal = „Cincizeci” tnDValue = tnDValue - 50

CAZ tnDValue < 70

lcStrVal = „Șaizeci” tnDValue = tnDValue - 60

CAZ tnDValue < 80

lcStrVal = „Șaptezeci”

tnDValue = tnDValue - 70

CAZ tnDValue < 90

lcStrVal = „Optzeci”

tnDValue = tnDValue - 80

CAZ tnDValue < 100

lcStrVal = „Nouăzeci”

tnDValue = tnDValue - 90

ENDCASE

*** Acum convertiți orice parte rămasă

lcStrTeen = con_teens(tnDValue)

DACĂ LEN(lcStrTeen) # 0

*** Adăugați textul relevant lcStrVal = lcStrVal + '-' + lcStrTeen ENDIF

RETURN TRIM(lcStrVal)

************************************************ *** Gestionați conversia unităților/adolescentilor

************************************************

FUNCȚIE con_adolescenti

LPARAMETRI tntvalue

FACE CAZ

CASE tntvalue = 0

ÎNTOARCERE('')

CASE tntvalue = 1

RETURN('Unul')

CASE tntvalue = 2

RETURN(„Doi”)

CASE tntvalue = 3

RETURN('Trei ')

CASE tntvalue = 4 RETURN('Patru ')

CASE tntvalue = 5 RETURN('Cinci ')

CASE tntvalue = 6 RETURN('Șase ')

CASE tntvalue = 7 RETURN('Șapte ') CASE tntvalue = 8 RETURN('Opt ') CASE tntvalue = 9 RETURN('Nouă ') CASE tntvalue = 10 RETURN('Zece ') CASE tntvalue = 11 RETURN('Unsprezece ') CASE tntvalue = 12 RETURN('Doisprezece ') CASE tntvalue = 13 RETURN('Treisprezece ') CASE tntvalue = 14 RETURN('Paisprezece ') CASE tntvalue = 15 RETURN('Fifteen ') CASE tntvalue = 16 RETURN ('Sixteen') CASE tntvalue = 17 RETURN('Șaptesprezece ') CASE tntvalue = 18 RETURN('Optsprezece ') CASE tntvalue = 19 RETURN('Nineteen ') ENDCASE

Designul de aici este interesant în sine. Problema a fost rezolvată prin reducerea la minimum a diferitelor componente ale unui număr, iar rezultatul este o funcție utilă care poate fi utilizată ca un apel pe o singură linie, după cum urmează:

lcOutStr = NumToStr(1372.23) + „Dolari”

Returnează: „O mie trei sute șaptezeci și doi și douăzeci și trei sutimi de dolari”

Cum se extrage un articol specificat dintr-o listă

Din ce în ce mai des trebuie să fim capabili să acceptăm și să interpretăm datele care sunt furnizate într-un format de listă separat. Acesta poate fi un fișier simplu, delimitat prin virgulă sau posibil rezultatul unui mecanism de transfer de date mai complex sau doar niște date pe care trebuie să le transmitem în interior. Construcția unui șir care conține date într-un format separat este destul de simplă. Preluarea datelor dintr-un astfel de șir, totuși, poate fi puțin mai problematică. Introduceți funcția GetItem().

Această funcție parsează șirul care i se dă, căutând apariția specificată a separatorului și extragând elementul pe care îl găsește. Se presupune că, dacă nu se specifică altfel, doriți primul element, iar separatorul este o virgulă. Cu toate acestea, ambele elemente pot fi specificate. Iată-l:

**************************************************** ********************

* 	Program.GetItem.PRG

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Extrage elementul specificat dintr-o listă ************************************* ********************************

FUNCȚIA GetItem(tcList, tnItem, tcSepBy)

LOCAL lcRetVal, lnStPos, lnEnPos, lcSepBy

lcRetVal = ""

*** Implicit la Separator virgulă dacă nu este specificat

lcSep = IIF ( VARTYPE(tcSepBy) # 'C' SAU EMPTY(tcSepBy ), 	, tcSepBy )

*** Implicit la primul articol dacă nu este specificat nimic

tnItem = IIF( TYPE( 'tnItem' ) # "N" SAU EMPTY (tnItem ), 1, tnItem)

*** Adăugați separator de terminal la listă pentru a simplifica căutarea

tcList = ALLTRIM( tcList ) + lcSep

*** Determinați lungimea șirului necesar

DACĂ tnItem = 1

lnStPos = 1

ALTE

lnStPos = AT( lcSep, tcList, tnItem - 1 ) + 1

ENDIF

*** Găsiți următorul separator

lnEnPos = AT( lcSep, tcList, tnItem )

DACĂ lnEnPos = 0 SAU (lnEnPos - lnStPos) = 0

*** Sfârșitul șirului

lcRetVal = NULL

ALTE

*** Extrageți elementul relevant

lcRetVal = SUBSTR.( tcList, lnStPos, lnEnPos - lnStPos )

ENDIF

*** Întoarce rezultatul

RETURNARE ALLTRIM(lcRetVal)

De obicei, folosim această funcție în interiorul unei bucle pentru a prelua elementele dintr-o listă separată în ordinea în care a fost construită, după cum urmează:

lcStr = „David|Jones|12 The Street|Someplace|”

lnCnt = 0

FĂ CÂND .T.

lnCnt

lnCnt + 1

IcItem = GetItem( IcStr, lnCnt, "|" )

DACĂ ! ISNULL(lcItem)

*** Fă orice cu el

ALTE

*** Sfârșitul șirului - ieșire

IEȘIRE

ENDIF

ENDDO

Există o modalitate simplă de a cripta parolele?

Răspunsul (și din moment ce am pus întrebarea, nu v-ați aștepta la nimic mai puțin) este Da! Următoarea pereche de funcții oferă o modalitate ușoară de a adăuga un nivel rezonabil de securitate a parolei. Procesul de criptare se bazează pe conversia fiecărui caracter din șirul simplu în numărul său ASCII și apoi pe adăugarea unei constante. Am folosit 17 în acest exemplu, dar sugerăm că, dacă adoptați aceste funcții, folosiți un număr diferit, plus un număr de început aleatoriu, plus poziția literei în șir la acea valoare. Caracterul reprezentat de acest număr nou este apoi returnat ca versiune criptată. Șirul returnat include numărul de semințe utilizat în generarea sa ca prim caracter, astfel încât să poată fi întotdeauna decodat. Această metodologie are mai multe beneficii:

• 	Același șir va produce, în limitele funcției RAND() de la Visual FoxPro, șiruri criptate diferite de fiecare dată când este trecut prin funcție

• 	Nu există o modalitate ușoară de a traduce un caracter criptat, deoarece rezultatul pentru orice caracter dat depinde de numărul de bază și de poziția acestuia în șir.

• 	Parola criptată este întotdeauna cu un caracter mai lungă decât originalul din cauza valorii de bază

• 	Nu există nicio restricție privind numărul de caractere (adică va gestiona parolele de 6, 8 sau 12 caractere la fel de bine)

• 	Parola poate include numere și caractere speciale

• 	Deși în niciun caz nu este sigur, este de fapt destul de dificil de piratat, deoarece, deși șirul simplu este întotdeauna convertit în majuscule, șirul criptat poate conține orice combinație de caractere

• 	Întrucât parola conține sămânța ei, un administrator poate oricând decoda parolele

Oricum, aici sunt ambele funcții de codificare și decodare: ******************************************* ********************************

* 	Program.AEnCode.PRG

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Criptați o parolă

**************************************************** ********************

FUNCȚIE aencode(tcKeyWord)

LOCAL lcRaw, lnVar, lcEnc

IF TYPE('tcKeyWord') # „C” SAU EMPTY(tcKeyWord)

*** Trebuie să treacă o cheie de caractere la acest proces

EROARE( „9000: Un șir de caractere este parametrul necesar pentru AEnCode” )

ÎNTOARCERE ""

ENDIF

lcRaw = UPPER(ALLTRIM(tcKeyWord)) && Cuvânt cheie

lnVar = INT (RAND() * 10) && Cheie cu numere aleatorii: 0 - 9

IcEnc = ALLTRIM(STR(lnVar)) && Șirul criptat începe cu cheia #

*** Analizați cuvântul cheie și criptați fiecare caracter

*** Folosind codul său ASCII + 17 + Cheie aleatorie + Poziție în cuvânt cheie

FOR lnCnt = 1 TO LEN(lcRaw)

IcChar = SUBSTR(lcRaw, lnCnt,1)

IcEnc = lcEnc + CHR( ASC(lcChar) + 17 + lnVar + lnCnt + 1)

URMĂTORUL

RETURN lcEnc

**************************************************** ********************

* 	Program. ...: ADeCode.PRG

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Decodifică o parolă criptată cu AEnCode() ************************************ **********************************

FUNCȚIE adecode(tcKeyWord)

LOCAL lcRaw, lnVar, lcEnc

IF TYPE('tcKeyWord') # „C” SAU EMPTY(tcKeyWord)

*** Trebuie să treacă o cheie de caractere la acest proces

EROARE( „9000: Un șir criptat este parametrul necesar pentru ADeCode” )

ÎNTOARCERE ""

ENDIF

lcEnc = ALLTRIM(tcKeyWord) && Cuvânt cheie

lnVar = VAL(LEFT(lcEnc,1)) && Cheie de criptare

lcRaw = "" && Parolă decodificată

*** Analizați cuvântul cheie și decriptați fiecare caracter

*** Folosind codul său ASCII + 17 + Cheie aleatorie + Poziție în cuvânt cheie

FOR lnCnt = 2 TO LEN(lcEnc)

lcChar = SUBSTR(lcEnc, lnCnt, 1)

lcRaw = lcRaw + CHR( ASC(lcChar) - (17 + lnVar + lnCnt) )

URMĂTORUL

RETURNARE lcRaw

Și iată câteva mostre ale rezultatului criptat:

Trecerea 1? AEnCode( 'Andy%Kr#02' ) 8\jawDksESV

Trecerea 2? AEnCode( 'Andy%Kr#02' ) 6Zh_uBiqCQT

Trecerea 3? AEnCode( 'Andy%Kr#02' ) 3We\r?fn@NQ

Fiecare dintre ele decodifică înapoi la același șir original:

Trecerea 1? ADeCode( '8\jawDksESV' ) ANDY%KR#02

Trecerea 2? ADeCode( '6Zh_uBiqCQT' ) ANDY%KR#02

Trecerea 3? ADeCode( '3We\r?fn@NQ' ) ANDY%KR#02

Suntem siguri că veți găsi modalități de îmbunătățire sau adaptare a acestor funcții, dar ne-au servit bine de câțiva ani și sperăm să vă placă.

Unde vrei să mergi?

Cu toții folosim comanda goto <nn> din când în când, dar una dintre micile supărări ale programelor Visual FoxPro este că GOTO nu efectuează singur verificarea erorilor. Dacă îi spui lui Visual FoxPro să GOTO un anumit număr de înregistrare, încearcă doar să meargă acolo. Desigur, dacă numărul de înregistrare pe care l-ați specificat nu este în tabel sau dacă ați selectat din greșeală zona de lucru greșită, obțineți o eroare urâtă.

Problema selectării zonei de lucru a fost în mare măsură rezolvată odată cu introducerea clauzei IN pentru multe comenzi - inclusiv GOTO. Cu toate acestea, asta nu rezolvă problema altor erori. Ne-am săturat să punem verificări în jurul fiecărei instrucțiuni GOTO din codul nostru, așa că am conceput o mică funcție pentru a încheia comanda GOTO și a o face mai sigură și mai prietenoasă. L-am numit GOSAFE() și iată-l:

**************************************************** ********************

* 	Program.GoSafe.PRG

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Înfășurare în jurul comenzii GOTO *************************************** ********************************

FUNCȚIA GoSafe(tnRecNum, tcAlias)

LOCAL ARRAY laErrs[1]

LOCAL lcAlias, lnCount, lnCurRec, lnErrCnt, lLRetVal

*** Parametrul de verificare este numeric și valid

IF VARTYPE (tnRecNum) # „N” SAU EMPTY(tnRecNum)

EROARE „9000: Un parametru numeric valid trebuie să fie transmis către GoSafe()”

RETURNARE .F.

ENDIF

*** Alias implicit la aliasul curent dacă nu este specificat

IF VARTYPE(tcAlias) #"C" SAU EMPTY(tcAlias)

lcAlias = ALIAS()

ALTE

lcAlias = UPPER( ALLTRIM( tcAlias ))

ENDIF

*** Verificați dacă avem aliasul specificat

DACA EMPTY(lcAlias) SAU ! FOLOSIT(lcAlias)

EROARE „9000: Nu a fost specificat niciun tabel sau tabelul specificat nu este deschis”

RETURNARE .F.

ENDIF

*** Obțineți Max Nicio înregistrare și cele selectate în prezent

*** numărul de înregistrare în aliasul specificat

lnCount = RECCOUNT( lcAlias )

lnCurRec = RECNO( lcAlias )

*** Salvați gestionarea erorilor și dezactivați captarea erorilor pentru moment

lcOldError = ON("EROARE")

LA EROARE *

*** Acum, încercați și mergeți la înregistrarea necesară

GOTO tnRecNum IN (lcAlias)

*** Am reușit?

IF RECNO( lcAlias ) # tnRecNum

*** Verificați erorile

InErrCnt = EROARE( laErrs )

DACĂ lnErrCnt > 0

FACE CAZ

CAZ laErrs[1,1] = 5

*** Înregistrare în afara intervalului

lcErrTxt = 'Numărul de înregistrare ' + AIITRIM(PADI(tnRecNum, 32)) ;

+ ' Nu este disponibil în Alias: ' + lcAlias

CAZ laErrs[1,1] = 20

*** Înregistrarea nu este în index

lcErrTxt = 'Numărul de înregistrare ' + AIITRIM(PADI(tnRecNum, 32)) ;

+ ' Nu este în Index pentru Alias: ' + lcAlias ;

+ CHR(13) + „Tabelul trebuie reindexat”

IN CAZ CONTRAR

*** O eroare neașteptată

lcErrTxt = „O eroare neașteptată a împiedicat GOTO să reușească” ENDCASE

MESSAGEBOX(lcErrTxt, 16, „Comandă eșuată”)

ENDIF

*** Restaurați înregistrarea inițială

GOTO lnCurRec IN (lcAlias)

llRetVal = .F.

EISE

llRetVal = .T.

ENDIF

*** Restore Error Handler

ON ERROR &lcOldError

RETURN llRetVal

Un lucru de observat în acest program este utilizarea funcției ON("EROARE") pentru a salva gestionarea erorilor curentă, astfel încât să putem suprima în siguranță gestionarea normală a erorilor cu ON ERROR * și să restabilim lucrurile la sfârșitul funcției.

Acesta este un punct foarte important și este prea ușor uitat în plină luptă. Orice procedură sau funcție ar trebui să salveze setările de mediu înainte de a modifica oricare dintre ele (ei bine, poate ar trebui să menționăm că cel mai bine este să validăm mai întâi parametrii. La urma urmei, dacă sunt incorecți, funcția oricum nu va face nimic.) La finalizare , procedura sau funcția dvs. trebuie să resetați totul exact așa cum era înainte de apelarea funcției.
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Capitolul 3-Design, design și nimic altceva

„Este prin proiect”. (Anonim, dar adesea asociat cu Microsoft Corporation)

Poți ghici despre ce este vorba în acest capitol? Corect, este vorba despre cele mai importante trei lucruri de luat în considerare atunci când lucrați cu mediul orientat obiect al Visual FoxPro. Nu suntem strict siguri că acest capitol cuprinde „Sfaturi”, dar cu siguranță este plin de sfaturi – majoritatea câștigate cu greu de-a lungul anilor în care am lucrat cu Visual FoxPro. Vom acoperi o gamă destul de mare de subiecte, începând cu câteva mementouri de bază despre ce este OOP.
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Deci, de ce toată agitația legată de OOP?

Este întotdeauna dificil să știi de unde să începi. În acest caz, am simțit că merită să începem cu câteva cuvinte despre de ce ar trebui să te deranjezi cu toate aceste lucruri OOP - și ce va însemna adoptarea paradigmei OOP pentru tine ca dezvoltator.

Primul aspect de făcut despre OOP este că nu este, în sine, un nou limbaj de programare, ci este de fapt un mod diferit de a privi modul în care proiectați și construiți programe de calculator. În ceea ce privește VFP, aceasta este vestea bună - înseamnă că de fapt nu trebuie să înveți o limbă complet nouă - doar un mod diferit de a face lucrurile. Vestea proastă este că noul mod de a face lucrurile este atât de radical diferit, încât probabil ți-ai dori să fii nevoit să înveți o nouă limbă. La fel ca multe aspecte ale programării, a face OOP este ușor, a face bine este mult mai greu!

Două dintre cele mai de bază beneficii pentru care programatorii s-au străduit de mult timp sunt reutilizarea (scrieți o bucată de cod o dată, depanați-o o dată și utilizați-o de mai multe ori) și extensibilitatea (faceți modificări unei părți a unui sistem fără a aduce restul acesteia). se prăbușește în jurul tău). Implementat corect, OOP are capacitatea de a oferi ambele beneficii. Singura întrebare este cum?

În primul rând, așa cum sugerează numele său, Orientarea obiectelor se concentrează pe „Obiecte” care sunt proiectate și create independent de aplicații. Lucrul cheie de reținut despre un obiect este că ar trebui să știe CUM să facă ceea ce este menit să facă. Cu alte cuvinte, un obiect trebuie să aibă o funcție. Dacă acea funcție este în întregime autonomă sau doar o verigă dintr-un lanț, este irelevant, cu condiția ca funcția să fie definită în mod clar ca fiind responsabilitatea unui anumit obiect.

În ceea ce privește o aplicație sau un sistem, funcționalitatea generală se realizează prin manipularea caracteristicilor și interacțiunilor obiectelor care alcătuiesc sistemul. Rezultă că modificările la funcționalitatea sistemului vor fi făcute prin adăugarea sau eliminarea obiectelor, mai degrabă decât prin modificarea codului dintr-un obiect existent.

Există, desigur, consecințe inerente adoptării acestei abordări a dezvoltării sistemului. În primul rând, va însemna o schimbare în accentul ciclului de dezvoltare. Va trebui să se aloce mult mai mult timp în proiectarea, crearea și testarea obiectelor cerute de o aplicație. Din fericire, va fi nevoie de mai puțin timp pentru a dezvolta sistemul. Până când aveți un stoc de obiecte testate corespunzător, veți avea, de asemenea, majoritatea funcționalității necesare unei aplicații și tot ce trebuie să faceți este să conectați lucrurile în mod corespunzător. (Până acum sună destul de bine.)

Desigur, există și o curbă de învățare. Nu doar în ceea ce privește mecanica programării în mediul OOP al Visual FoxPro (acesta este partea ușoară), ci și a învăța să schimbați modul în care vă gândiți la munca de dezvoltare. Vestea proastă este că, deși nu a existat niciodată un înlocuitor pentru designul software bun, în lumea OOP designul nu este doar critic, ci este totul! Obțineți designul original corect și totul este simplu. Găsiți greșit și viața devine rapid o mizerie.

Ultima veste proastă este că nu numai designul este critic, ci și documentația. Deoarece obiectivul dvs. este să scrieți o bucată de cod o dată și o singură dată și apoi să o închideți pentru totdeauna, este imperativ să documentați ce face fiecare obiect, ce informații are nevoie și ce funcționalitate oferă. (Rețineți că nu trebuie să știm cum face orice ar face - aceasta este responsabilitatea obiectului.)
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Deci, ce înseamnă tot acest jargon OOP?

Ca și în cazul oricărei tehnologii noi, apariția Orientării obiectelor a introdus o mulțime de cuvinte și expresii noi în limbajul de dezvoltare FoxPro. În timp ce majoritatea jargonului este „standard” în lumea orientată pe obiecte, nu este întotdeauna imediat evident pentru cei dintre noi care provin dintr-un fundal FoxPro. Lucrul cu obiecte necesită o înțelegere a PEM-urilor (Properties, Events and Methods). Ce înseamnă de fapt acești termeni?

Copyright 2000 de către Marcia Akins, Andy Kramek și Rick Schummer Toate drepturile rezervate

Proprietate

O proprietate a unui obiect este o variabilă care definește o anumită caracteristică a acelui obiect. Toate obiectele au un „Set” implicit de proprietăți (derivat inițial din definiția clasei) care descriu starea obiectului.

De exemplu, un obiect casetă de text are proprietăți pentru:

• 	Dimensiunea și locația (de exemplu, înălțime, lățime, sus, stânga)

• 	Aspect (de exemplu FontName, FontSize)

• 	Stare (de ex. ReadOnly)

• 	Conținut (de ex. Controlsource, Value)

Setul de proprietăți al unui obiect poate fi extins în Visual FoxPro prin adăugarea de „proprietăți personalizate” la definiția clasei din care este derivat obiectul.

Proprietățile răspund la întrebarea: „Care este starea obiectului?”
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Metodă

O metodă a unui obiect este o procedură asociată cu acel obiect. Toate obiectele au un „Set” implicit de metode (derivat inițial din definiția clasei) care definesc modul în care se comportă un obiect. De exemplu, un obiect casetă text are metode pentru:

• 	Se actualizează (reîmprospătare)

• 	Transformarea unui obiect în curent (SetFocus)

• 	Schimbarea poziției sale (Mutare)

Setul de metode al unui obiect poate fi extins în Visual FoxPro prin adăugarea de „metode personalizate” la definiția clasei.

Metodele răspund la întrebarea: „Ce face obiectul?”
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Eveniment

Un eveniment este o acțiune pe care un obiect o poate recunoaște și la care poate răspunde. Toate obiectele au un „Set” implicit de evenimente pe care le moștenesc din clasa de bază FoxPro. Astfel, de exemplu, un obiect casetă de text poate recunoaște evenimente precum:

• 	Acțiuni cu mouse-ul sau tastatură

• 	Modificări ale valorii curente

• 	Primirea sau pierderea focalizării

Acțiunea pe care o întreprinde un obiect atunci când are loc un eveniment este determinată de conținutul unei metode asociate evenimentului. Cu toate acestea, apelarea directă a unei astfel de metode NU provoacă declanșarea evenimentului, ci doar execută metoda. Anumite evenimente au acțiuni implicite în metodele lor, care sunt definite de clasa de bază FoxPro (de exemplu, GotFocus), în timp ce altele nu au (de exemplu, Click).

Setul de evenimente al unui obiect nu poate fi extins - nu puteți crea „evenimente personalizate”. Cu toate acestea, codul poate fi adăugat la metoda asociată unui eveniment pentru a apela o altă metodă.

Evenimentele răspund la întrebarea: „Când face obiectul ceva?”

Copyright 2000 de către Marcia Akins, Andy Kramek și Rick Schummer Toate drepturile rezervate

Mesaje

Un mesaj este rezultatul acțiunii unui obiect și este mecanismul prin care acesta comunică cu mediul său. În Visual FoxPro, mesajele sunt gestionate prin transmiterea de parametri/returnarea valorilor sau prin setarea proprietăților/metodelor de apelare.

Mesajele răspund la întrebarea „De unde știm că un obiect a făcut ceva?”
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Clase și Obiecte

Înțelegerea diferenței dintre o clasă și un obiect este crucială pentru OOP. O clasă este șablonul din care sunt create obiectele. Cu toate acestea, obiectele nu sunt „copii” ale unei definiții de clasă, ele sunt referințe la aceasta. Consecința este că atunci când o definiție de clasă este modificată, orice obiect derivat din acea clasă va reflecta acea modificare. Aceasta este ceea ce se înțelege prin „Moștenire”.

Relația dintre un obiect și clasa sa este similară cu cea dintre o rețetă pentru un tort și tortul propriu-zis - rețeta vă spune cum să faceți tortul, dar nu puteți mânca de fapt rețeta! În același mod, o clasă nu face nimic. Numai atunci când un obiect este creat ca o „INSTANȚĂ” a acelei clase (procesul se numește, prin urmare, „Instantiatiori), orice lucru util poate fi făcut efectiv.

În Visual FoxPro, clasele pot fi definite ierarhic, iar obiectele pot fi instanțiate de la orice nivel al ierarhiei. Este important, prin urmare, ca definirea claselor să fie întreprinsă folosind o metodologie logică și consecventă - denumită Abstracție'. Principiul din spatele abstractizării este identificarea caracteristicilor cheie adecvate nivelului de ierarhie luat în considerare.

Acest lucru sună mai complex decât este de fapt - cu toții o facem în fiecare zi fără să ne gândim la asta. De exemplu, dacă cineva ar spune „Dă-mi un stilou”, în mod normal nu am ezita să luăm în considerare ce este de fapt un „pix” – doar „știm ce este un stilou”.

De fapt, nu există „un stilou” - termenul este de fapt o abstracție care descrie o clasă de obiecte fizice care au anumite caracteristici și care diferă de alte clase de obiecte fizice. În mod normal, nu am confunda un pix și un creion - chiar dacă ambele sunt în mod clar instrumente de scris.

Acest principiu de bază se traduce direct în construirea de clase în cadrul VFP. Începând cu clasele de bază VFP ne putem construi propriile ierarhii de clasă adăugând la funcționalitate (Augmentare) sau schimbând funcționalitatea (Specializare) în subclase care formează apoi Ierarhia Claselor.
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Moştenire

Moștenirea este termenul folosit pentru a descrie modul în care un obiect (o „Instanță” a unei clase) își derivă funcționalitatea din clasa sa părinte. În Visual FoxPro, ori de câte ori utilizați un obiect, de fapt creați o referință înapoi la acea definiție a clasei părinte. Această referință nu este statică și este reevaluată de fiecare dată când obiectul este instanțiat. Rezultatul este că, dacă modificați definiția în clasa părinte, orice obiect bazat pe acea clasă va afișa rezultatul modificării data viitoare când este instanțiat.

Acesta este motivul pentru care atunci când lucrați în Visual FoxPro, veți primi ocazional un mesaj de eroare care spune „Nu se poate modifica o clasă care este în uz”. Ceea ce vă spune aceasta este că aveți de fapt una sau mai multe definiții în memorie care sunt cerute de obiectul pe care încercați să îl editați. Emiterea unei comenzi „clearall” va rezolva de obicei această problemă pentru dvs.

Cum implementează VFP moștenirea

Visual FoxPro implementează moștenirea într-un mod de jos în sus. Când are loc un eveniment care necesită ca un obiect să ia o anumită acțiune, Visual FoxPro începe prin a executa orice cod care a fost definit în metoda asociată cu acel eveniment în obiect (un astfel de cod este, prin urmare, denumit „Nivel de instanță” și este va suprascrie orice cod moștenit, cu excepția cazului în care un apel explicit al funcției „dodefault()” este inclus la un moment dat).

Dacă nu există cod în obiect (sau a fost specificat un DoDefault()), VFP continuă prin executarea oricărui cod definit în aceeași metodă în clasa identificată în proprietatea ParentClass a obiectului. Acest proces continuă în sus în ierarhia definită de referințele succesive ParentClass până când este găsită fie o metodă care conține cod fără un DoDefault() explicit, fie o clasă în care proprietatea ParentClass indică direct către o clasă de bază Visual FoxPro. Oricare dintre condiții identifică „Sup” al ierarhiei de clasă pentru acel obiect și nu se caută alte referințe.

La finalizarea oricărui cod la nivel de instanță și a oricărui cod moștenit, Visual FoxPro rulează în cele din urmă orice cod care este definit în metoda clasei de bază native relevante. (Orice astfel de cod va fi întotdeauna executat, cu excepția cazului în care includeți o comandă explicită nodefault undeva în lanțul de moștenire.) Din păcate, nu există documentație care să vă spună care metode de clasă de bază au de fapt cod executabil, deși unele sunt evidente. KeyPress, GotFocus și LostFocus sunt toate exemple de evenimente care necesită comportament nativ și care, prin urmare, au cod în clasele de bază. În schimb, există evenimente care, evident, nu au niciun comportament nativ - Click, When și Valid sunt toate exemple de metode de clasă de bază care pur și simplu returnează valoarea implicită (un .T. logic).

„Capcana” moștenirii

Moștenirea pare, la prima vedere, să întruchipeze însăși esența lucrului într-o manieră orientată pe obiect. Definind o clasă și apoi creând subclase care sunt fie augmentate, fie specializate, s-ar părea că putem simplifica foarte mult sarcina de a construi o aplicație. Cu toate acestea, există o capcană subtilă în a te baza prea mult pe moștenire, așa cum ilustrează următorul exemplu simplu.

Să presupunem că dorim să creăm o clasă Form standard pe care o vom folosi în toate aplicațiile noastre. Decidem că un lucru de care va avea nevoie fiecare formular este un „buton Exif și așadar adăugăm un buton de comandă cu subtitrări adecvat clasei noastre de formulare și în metoda sa Click, plasăm un apel „ThisForm.Release()”. Este foarte bine și de fiecare dată când creăm un formular nou, acesta vine complet cu un buton „Ieșire” care funcționează, deși nu există niciun cod în metoda Click a butonului. (Desigur că există într-adevăr cod, dar în loc să fie în fiecare formă, acesta există o singură dată - în butonul pe care l-am definit ca parte a clasei Form și la care se referă întotdeauna butonul de pe fiecare instanță a clasei noastre de formular). Până acum, bine. De-a lungul timpului, adăugăm mai multe funcționalități „standard” la clasa noastră de formulare, creând proprietăți și metode personalizate pentru a ne gestiona nevoile.

Apoi, într-o zi, ni se cere să creăm un formular nou care, în loc de un buton „Ieșire”, are două butoane „OK și „Anulează”. Primul trebuie să „salveze modificările și să iasă din formular”, iar al doilea trebuie să „renunțe modificările și să iasă din formular”. Avem imediat o problemă pentru că nu putem crea pur și simplu o subclasă a formularului nostru standard! Orice subclasă va avea ÎNTOTDEAUNA un buton „Ieșire” care pur și simplu eliberează formularul și nu putem șterge acel buton dintr-o subclasă, deoarece Visual FoxPro se va plânge că „Nu pot șterge obiecte deoarece unele sunt membri ai unei clase părinte”. Desigur, am putea pur și simplu să creăm o nouă subclasă a clasei de bază a formularului, dar aceasta nu ar avea niciuna dintre celelalte proprietăți și metode personalizate! Ar trebui să le adăugăm pe toate din nou și să copiem și să lipim codul în noua noastră clasă de formulare, creând astfel două seturi de cod pentru a menține pentru totdeauna mai mult și pierzând unul dintre principalele beneficii ale utilizării Orientării obiectelor.

O soluție pe care am văzut-o pentru această dilemă este să mergem mai departe și să creăm oricum subclasa. Apoi, în acea subclasă, proprietățile Enabled și Visible ale butonului Exit moștenite sunt setate la FALSE și sunt adăugate butoanele noi necesare! OK, va funcționa, dar suntem siguri că veți fi de acord, nu este tocmai cel mai bun mod de a face lucrurile.

Abordarea corectă este, așa cum explicăm în secțiunea „Deci, cum să proiectați o clasă” de mai jos în acest capitol, este să vă proiectați clasele în mod corespunzător și, în loc să vă bazați în întregime pe moștenire, să utilizați compoziția pentru a adăuga funcționalități specifice atunci când Este nevoie.
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Compoziţie

Compoziția este un termen folosit pentru a descrie tehnica în care unei clase i se oferă acces la un anumit comportament (sau funcționalitate) prin adăugarea unui obiect care are deja acel comportament, mai degrabă decât prin adăugarea de cod direct la clasă. Aceasta este de fapt o modalitate mult mai bună de a construi obiecte complexe decât să te bazezi direct pe moștenire, deoarece vă permite să definiți funcționalitatea în unități discrete care pot fi reutilizate în multe situații diferite. (Este, de asemenea, cel mai bun mod de a evita „capcana moștenirii” prezentată în secțiunea precedentă.)

Cel mai important, nu sunteți limitat la utilizarea compoziției doar în momentul proiectării. Toate containerele Visual FoxPro (adică acele clase care pot „conține” alte obiecte - inclusiv Forms and Toolbars, PageFrames and Pages, Grids and Columns, precum și clasele Container și Custom)) au metode native AddObject și RemoveObject care fac utilizarea compoziției în timpul executării o chestiune relativ simplă. (Pentru o reprezentare schematică a categorizării claselor de bază, consultați „Capitolul 3: Programarea orientată pe obiecte” din Ghidul programatorului sau documentația online.)

Rezultatul utilizării compoziției, fie la proiectare, fie în timpul executării, este întotdeauna că obiectul adăugat devine un „copil” (sau „membru”) al obiectului la care este adăugat. Acest lucru asigură că obiectul copil are aceeași durată de viață ca și părintele său - atunci când părintele este distrus, la fel și toți copiii săi.

În cele din urmă, rețineți că compoziția nu se limitează la anumite tipuri de clase - este perfect posibil (și permis) să amestecați clase vizuale și non-vizuale în același obiect compozit. Singura restricție este că obiectul părinte vizat trebuie să se bazeze pe o clasă care este capabilă să conțină tipul de obiect care urmează să fie adăugat. Cu alte cuvinte, nu puteți adăuga un obiect bazat pe o clasă „coloană” Visual FoxPro la altceva decât o grilă, indiferent de modul în care îl definiți.
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Agregare

Agregarea este termenul folosit pentru a descrie tehnica în care unei clase i se oferă acces la un anumit comportament (sau funcționalitate) prin crearea unei referințe la un obiect care are deja acel comportament, mai degrabă decât prin adăugarea de cod direct la clasă. Dacă acest lucru sună similar cu compoziția, este, deoarece compoziția este de fapt un caz special de agregare. Diferența este că agregarea se bazează pe crearea unei referințe la un obiect ca membru al clasei, în timp ce compoziția necesită ca obiectul copil însuși să fie creat ca membru al clasei. Consecința este că agregarea nu se limitează la clasele de container și nu există nicio cerință ca obiectul agregat să aibă aceeași durată de viață ca și obiectul care se referă la el.

Tocmai pentru că agregarea se bazează pe „cuplarea liberă” între obiecte este atât mai flexibilă decât compoziția și potențial mai periculoasă. Este mai flexibil, deoarece nu necesită containership direct (astfel încât, de exemplu, unui obiect bazat pe o clasă de casete text i se poate da o referință directă la un alt obiect bazat pe o clasă DataEnvironment). Este mai periculos deoarece durata de viață a obiectului care deține referința și a obiectului referit nu sunt legate direct. Trebuie să vă asigurați că orice referințe sunt rezolvate corect atunci când eliberați oricare dintre obiecte și acest lucru poate fi dificil în Visual FoxPro, deoarece nu există nicio modalitate ca un obiect să știe ce referințe externe la el pot exista în orice moment.

Cea mai simplă formă de agregare (și, prin urmare, cea mai sigură) este atunci când un obiect creează de fapt obiectul țintă însuși și atribuie referința acelui obiect direct uneia dintre proprietățile sale. Forma mai complexă este atunci când un obiect fie transmite o referință la el însuși unui alt obiect, fie dobândește o referință la un obiect existent.
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Delegație

Delegarea este termenul folosit pentru a descrie situația în care un obiect îi instruiește pe altul să efectueze o acțiune în numele său. Este, efectiv, o formă de moștenire fără clasă, deoarece permite accesarea funcționalității care aparține de fapt obiectelor unei clase specifice de către obiectele care nu moștenesc din acea clasă. Acesta este un instrument extrem de puternic în arsenalul dezvoltatorului, deoarece ne permite să ne centralizăm codul și să apelăm la el atunci când este necesar.

Puterea delegării poate fi văzută atunci când luați în considerare situația în care aveți nevoie de controale pentru ca un formular să fie implementat fie ca obiecte conținute (de ex. Butoane de comandă), fie ca obiecte de sine stătătoare (de exemplu, o Bară de instrumente). Evident, situația cu butoanele dintr-un formular este destul de ușoară - butoanele aparțin formularului până la urmă, astfel încât codul poate fi plasat în propriile metode. Cu toate acestea, o bară de instrumente este mai dificilă.

A oferi diferite bare de instrumente pentru fiecare tip de formular ar fi atât consumator de timp, cât și risipă de resurse, pentru a nu spune dificil de întreținut. Adăugând cod direct la metodele de formulare standard, este posibil să codificați atât barele de instrumente, cât și butoanele în mod generic, astfel încât un singur set de butoane sau bară de instrumente (sau ambele) să poată fi utilizate cu orice formular. Fiecare buton individual, oriunde s-ar afla, își poate delega funcția unei metode din forma activă în prezent - care, apropo, este în totalitate în concordanță cu definiția noastră anterioară a obiectelor care trebuie să știe cum să facă ceva, fără a avea nevoie de fapt. pentru a sti cum este implementat.
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Încapsulare

Există două aspecte ale încapsulării. Primul este că un obiect trebuie să fie de sine stătător și că nu pot exista dependențe de modul în care funcționează un obiect în afara obiectului însuși. În mod clar, dacă astfel de dependențe ar fi permise, moștenirea nu ar funcționa corect, deoarece o modificare a modului în care a fost definită o clasă ar afecta nu numai acele obiecte care derivă din acea clasă, ci și obiecte care depind de obiectele derivate care funcționează într-un anumit mod.

A doua este cerința de a proteja funcționarea interioară a unui obiect de mediul său. Acest lucru este necesar pentru a vă asigura că un obiect își poate îndeplini funcția alocată în mod fiabil în toate situațiile și urmează din prima.

Mecanismul de definire a interacțiunii unui obiect cu mediul său este denumit „Interfață publică”. Multe dintre așa-numitele limbaje OOP „pure” necesită încapsularea totală a unui obiect și limitează interfața publică la câteva metode specifice „Get and Set”. Visual FoxPro (la bine și la rău) este mai deschis și, în mod implicit, un obiect își expune toate PEM-urile în interfața publică, cu excepția cazului în care se solicită altfel. Metodele „Acces” și „Atribuire”, introduse în Visual FoxPro Versiunea 6.0, corespund în multe feluri metodelor Get și Set menționate mai sus, deși implementarea este diferită.
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Polimorfism

Polimorfismul este o caracteristică a limbajelor orientate pe obiecte care apare din cerința ca, atunci când se apelează la o metodă a unui obiect, referința la obiect trebuie inclusă ca parte a apelului. Consecința este că este perfect posibil să existe metode care au același nume în mai multe obiecte diferite, dar care de fapt fac lucruri diferite în obiecte diferite. Apelul la o metodă are sens doar în contextul unui obiect specific și, prin urmare, nu există nicio posibilitate de confuzie.

Acesta este un instrument foarte puternic în contextul dezvoltării și întreținerii aplicațiilor, deoarece permite ca obiectele să fie adăugate sau schimbate unul cu celălalt, fără a fi necesar să se schimbe efectiv codul aplicației de lucru.
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Ierarhiile

Când lucrați în Visual FoxPro, este important să rețineți că există două ierarhii distincte cu care interacționați:

• 	Prima este ierarhia „Clasă” (sau „Moștenire”) care este definită de relațiile diferitelor clase pe care le creați. Relația unui obiect (prin clasa sa părinte) cu această ierarhie este cea care determină ce PEM-uri va moșteni. Construcția și managementul Ierarhiei de clasă este, prin urmare, în esență o problemă de „timp de proiectare”.

• 	Al doilea este ierarhia „Obiect” (sau „Containership”). Aceasta este determinată de relațiile dintre obiecte (indiferent de Clasa lor) și containerele în care se află. Poziția unui obiect în această ierarhie este cea care determină modul în care trebuie să gestionați interacțiunile acestuia cu alte obiecte. În timp ce construcția ierarhiei obiectelor poate fi inițiată în timpul proiectării, gestionarea acesteia este, în esență, o problemă de „timpul de rulare”.
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Programare practică orientată pe obiecte (POOP)

Atât de mult pentru teorie, acum să trecem la câteva probleme mai practice. Întrebarea cheie este cum putem transforma toată această teorie în practică? Despre asta este POOP! (Apropo, am observat că „Regulile celor trei” joacă un rol important în lumea POOP).
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Când ar trebui să definiți o clasă?

Imediat atingem prima noastră „Regulă de trei”, care definește criteriile pentru a decide că este necesară o nouă clasă (sau o nouă subclasă a unei clase existente). Acestea, sugerăm, sunt:

• 	Obiectul va fi reutilizat?

• 	Va ușura gestionarea complexității?

• 	Merită efortul?

Reutilizabilitate

Acesta este probabil cel mai frecvent motiv pentru crearea unei clase, iar realizarea reutilizabilității este, la urma urmei, unul dintre obiectivele principale ale POO La cel mai simplu nivel, acest lucru poate însemna atât de puțin decât configurarea propriilor preferințe personale pentru obiecte - Font , Culoare și Stil, de exemplu, astfel încât toate obiectele clasei dvs. să fie create cu setările corecte.

Lucrurile devin puțin mai complicate când iei în considerare funcționalitatea. Cât de des, în practică, faci exact același lucru, exact în același mod, pentru a obține exact aceleași rezultate, exact în același mediu? Răspunsul este probabil „nu foarte des” și poate chiar începeți să vă întrebați dacă reutilizarea este atât de valoroasă până la urmă. Acest lucru ne conduce clar la al doilea criteriu.

Gestionarea complexității

După cum am sugerat în secțiunea precedentă, este de fapt foarte rar ca orice altceva decât cele mai simple clase funcționale să poată fi pur și simplu reutilizat „ca atare”. Există aproape întotdeauna diferențe în ceea ce privește mediul, cerințele de intrare sau de ieșire și uneori toate. Această complexitate aparentă poate ascunde uneori problema, și anume că funcționalitatea dorită rămâne constantă, deși implementarea poate diferi în detaliu între aplicații.

Aplicând regulile de proiectare a claselor prezentate în secțiunea următoare, ar trebui să vă fie mai ușor să decideți dacă utilizarea unei clase va ușura gestionarea acestei complexități sau nu. Chiar dacă crearea unei clase ar putea ușura gestionarea complexității, tot trebuie să luăm în considerare al treilea criteriu.

Merită efortul?

Vă veți aminti că am afirmat mai sus că un obiect ar trebui să fie încapsulat astfel încât să conțină în sine toate informațiile necesare pentru a-și îndeplini sarcina și că niciun obiect nu ar trebui să se bazeze vreodată pe implementarea internă a unui alt obiect.

În mod clar, acest lucru poate face viața extrem de dificilă. Ar putea însemna că clasa dvs. va trebui să verifice zeci de condiții posibile pentru a determina (pentru ea însăși) exact care este starea sistemului înainte de a-și putea îndeplini funcția alocată. Când luați în considerare crearea unei noi clase, este important să vă asigurați că merită efectiv efortul de a face acest lucru.
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Așadar, cum faci despre proiectarea unei clase?

Prima și cea mai de bază cerință este să fii sigur că știi ce va face de fapt clasa. Acest lucru poate suna evident, dar există o capcană subtilă aici. Este foarte ușor să construiți atât de mult în fiecare clasă pe care o proiectați, încât înainte să vă dați seama, ați construit clase care nu sunt reutilizabile pentru că fac prea multe! Soluția este întotdeauna să fii sigur că ai identificat „responsabilitățile” clasei tale și că le-ai clasificat înainte de a începe să scrii cod.

O responsabilitate poate fi definită aici simplu ca „un element de funcționalitate care trebuie completat”. Această clasificare, în conformitate cu „Regulile celor trei”, se poate face prin atribuirea fiecărei responsabilități identificate uneia dintre cele trei case de porumbei, după cum urmează:

• 	Trebuie să faceți

• 	Ar putea face

• 	Ar trebui gata

Acțiunile care se încadrează în prima categorie „Trebuie să faceți” sunt acele lucruri pe care un obiect derivat din clasă ar trebui să le facă în orice situație și sunt, prin urmare, în mod clar responsabilitățile directe și unice ale clasei. Acestea trebuie să facă parte din definiția clasei.

Lucrurile care intră în categoria „S-ar putea face” sunt în mod normal indicatori că clasa poate necesita fie una sau mai multe subclase (sau, mai rar, cooperarea obiectelor unei alte clase). Cu alte cuvinte, acestea sunt lucrurile pe care clasa ar fi posibil să le facă, dar care nu ar fi de fapt necesare în orice situație. Includerea unor astfel de elemente „S-ar putea face” într-o definiție de clasă este cea care poate împiedica de fapt acea definiție să fie reutilizată în mod corespunzător.

Categoria finală este într-adevăr foarte importantă. Aceasta este categoria care definește „ipotezele” pe care o clasă trebuie să le fi îndeplinit pentru a funcționa corect. Elementele enumerate aici nu sunt cu siguranță responsabilitatea exclusivă a clasei în cauză, dar trebuie, totuși, făcute cumva.

După ce ați definit și clasificat responsabilitățile noii clase, trebuie să definiți interfața publică a acesteia, hotărând ce proprietăți și metode va avea nevoie și cum se va dezvălui altor obiecte cu care va interacționa.

În cele din urmă, puteți codifica definiția clasei, instanțiați un obiect din ea și testați-l (minus). Dar când totul este gata, încă nu ați terminat pentru că TREBUIE să documentați în detaliu noua clasă și orice subclase.
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Toate acestea sună foarte bine, dar ce înseamnă în practică?

Luați în considerare un exemplu simplu. Crearea unei bare standard de navigare în tabel care ar putea arăta cam așa:

Primul 	PrevNextUltimul
' 	:			

Figura 3.1 O bară standard de navigare în tabel

Avem nevoie de o clasă pentru asta?

Urmând pașii menționați mai sus, putem evalua necesitatea clasei după cum urmează:

• 	Va fi reutilizabil? Deși acest lucru va depinde, într-o oarecare măsură, de tipul de aplicații pe care îl construiți, navigarea printr-un tabel (sau cursor sau vizualizare) este o cerință fundamentală și, prin urmare, aceasta ar trebui să fie reutilizată în multe situații diferite.

• 	Ne va ajuta să gestionăm complexitatea? Răspunsul aici este, de asemenea, „da”. Sarcina reală de a naviga între înregistrările dintr-un tabel, cursor sau vizualizare nu este deosebit de dificilă în Visual FoxPro. Dar există încă probleme care trebuie tratate (cum ar fi ce să faci la începutul sau la sfârșitul unui fde, de exemplu).

• 	Merită efortul de a crea clasa? Având în vedere răspunsurile la primele două întrebări, aceasta este o idee simplă - este destul de clar că avem într-adevăr nevoie de o clasă pentru această sarcină.

Deci, care vor fi responsabilitățile clasei?

Acesta este unul ușor - dacă se va ocupa de navigarea între înregistrări dintr-un tabel, cursor sau vizualizare! Din păcate, deși aceasta descrie intenția, nu ne spune cu adevărat care sunt „responsabilitățile” clasei. Cel mai bun mod pe care l-am găsit de a face acest lucru este să scriem toate lucrurile la care ne putem gândi - așa cum ni se întâmplă - astfel (aceasta nu este nicidecum o listă completă):

• 	Afișați mesajul pentru reciclare la BOF()/EOF()

• 	Asigurați-vă că Tabelul de date este deschis

• 	Asigurați-vă că înregistrările sunt disponibile

• 	Gestionați erorile BOF()/EOF().

• 	Mutați indicatorul de înregistrare

• 	Actualizează formularul de părinte

• 	Selectați Zona de lucru corectă

• 	Butoanele de activare/dezactivare selectivă

• 	Selectați Câmp specific la finalizare

După ce ne-am creat lista, aplicăm regula „Trebuie-Ar putea-Ar trebui” fiecărui element pentru a ne rafina definiția - rezultatul ar putea arăta ceva de genul:

Tabelul 3.1 Lista rafinată de responsabilități

Responsabilitate

Categorie

Afișează mesajul pentru reciclare la BOF()/EOF() 	Poate
că Tabelul de date este deschis	
Asigurați-vă că înregistrările sunt disponibile 	Ar trebui
Tratați erorile BOF()/EOF() 	Trebuie
Mutați indicatorul de înregistrare 	Trebuie
Reîmprospătați formularul părinte 	trebuie
Selectați Zona de lucru 	corectă
Butoanele de activare/dezactivare selectivă 	trebuie
Selectați un câmp specific la 	finalizare

Din această listă putem vedea imediat că avem patru articole „Must-Do”. Acestea vor fi necesare în toate situațiile și trebuie să formeze baza definiției clasei. Cele două elemente „Could-Do” s-ar aplica în mod clar doar în situații speciale și, prin urmare, sunt candidați pentru subclase, deoarece nu ne-am dori niciunul dintre aceste comportamente în toate situațiile.

Cele trei elemente „Ar trebui să faci” sunt mai interesante. În mod clar, clasa noastră nu va funcționa dacă nu este disponibil niciun tabel sau dacă este deschis, dar nu conține înregistrări, dar atunci nici (probabil) nu ar funcționa nimic altceva pe formularul care găzduiește controlul. În ceea ce privește selectarea zonei „corecte”, de ce ar trebui să aibă grijă barei de navigare în ce tabel navighează? Niciuna dintre acestea nu este sarcini care se referă exclusiv la clasa barei de navigare - toate au ramificații mai largi și ar trebui abordate în afara acestei clase.

Mai simplu spus, funcția clasei barei de navigare este de a muta indicatorul de înregistrare, de a gestiona orice erori care ar putea apărea din acea mișcare și de a-și actualiza forma părinte când a terminat. Nicio altă clasă

ar putea gestiona oricare dintre aceste sarcini și nu există sarcini aici care să nu se refere exclusiv la clasa în cauză.

Aceasta arată acum ca o definiție de lucru și putem trece la etapa următoare.
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Cum procedați pentru a vă construi clasele?

Iată o altă „Regulă de trei” - de data aceasta legată de modul în care proiectați și construiți bibliotecile de clasă și clasele din acestea.

• 	Proiectați-vă structura clasei ca întreg înainte de a codifica orice

• 	Căutați modele atunci când definiți clase

• 	Cod în Metode, nu în Evenimente

Structura bibliotecii de clasă

Nu există reguli stricte și rapide în acest sens. De fapt, Visual FoxPro este remarcabil de flexibil în acest sens (o bibliotecă de clase este doar un tabel până la urmă) și nu face niciun fel de presupuneri despre bibliotecile de clase. Dacă doriți, puteți păstra toate clasele și subclasele lor într-o singură bibliotecă. Cu toate acestea, probabil că acest lucru ar deveni puțin greu de manevrat după un timp, așa că este recomandat să lucrați într-o structură logică de bibliotecă. O altă considerație de reținut este că atunci când lucrați într-un mediu de echipă, sub controlul sursei, păstrarea tuturor orelor într-o singură bibliotecă poate îngreuna într-adevăr întreținerea!

În esență, puteți diferenția clasele în trei grupuri (încă o „regula a trei”):

• 	Clase rădăcină (abstracte).

• 	Clase generice

• 	Clase specifice aplicației

Clasele rădăcină sunt subclasele tale personale ale claselor de bază VFP pe care sunt construite toate celelalte clase. Acestea nu ar trebui să fie folosite niciodată pentru a instanția obiecte direct, la fel și clasele „abstracte”. Clasele generice sunt cele care nu sunt specifice unei anumite aplicații și ar consta în mod normal din controalele dumneavoastră standard. Clasele specifice aplicației sunt, desigur, cele create pentru o aplicație și vor fi subclasele fie ale claselor dvs. rădăcină, fie una (sau mai multe) dintre clasele generice.

Dacă alegeți să vă subdivizați în continuare bibliotecile, depinde, desigur, în întregime de dvs. Păstrăm toate clasele noastre de formulare într-o bibliotecă separată. De asemenea, creăm biblioteci individuale pentru grupuri de clase care sunt legate de funcționalități specifice. („Graphics.vcx” nostru este un exemplu de bibliotecă funcțională. Toate clasele din această bibliotecă sunt preocupate de afișarea grafică a diferitelor tipuri de informații pe ecran. Acest lucru permite excluderea întregii biblioteci dintr-o aplicație dacă nu este necesar).

Căutați modele

Modelele de design sunt o modalitate de a comunica experiența și cunoștințele de proiectare, deoarece problemele au întotdeauna nevoie de soluții. În mod firesc, probleme similare tind să genereze soluții similare și motivul pentru care soluțiile sunt similare este că au un nucleu comun sau o abordare comună pentru rezolvarea problemei. Un model de design este pur și simplu o recunoaștere a unui astfel de nucleu și o descriere a acelui nucleu în așa fel încât să poată fi utilizat în multe scenarii diferite. Este, pe scurt, o descriere generică a modului de rezolvare a unei probleme. Rețineți totuși că un model de design nu este o soluție la o problemă. Modelele sunt la fel de relevante în contextul proiectării claselor ca și în proiectarea aplicațiilor. Când vă proiectați propriile clase, este important să căutați modele în cerințele dvs., astfel încât clasele dvs. în sine să reflecte modelele pe care le veți folosi atunci când sunt implementate.

De departe cea mai bună referință pe care am găsit-o până acum pentru a învăța despre modele este excelenta „Design Patterns, Elements of Reusable Object-Oriented Software”, de Gamma, Helm, Johnson și Vlissides, publicat de Addison-Wesley. Vă recomandăm insistent să obțineți o copie a acestei cărți, fie pe hârtie (ISBN 0-201-63361-2) pentru a putea mâzgăli pe margini, fie în formatul CD mai nou (ISBN 0201-63498-8) pentru a putea purtați-l în jur, căutați-l și citați din el mai ușor.

Codați în metode, nu în evenimente

Aceasta nu este cu adevărat o regulă, dar credem că este o practică bună. Când vă codificați clasele, încercați să evitați plasarea codului direct în metodele și evenimentele native ale Visual FoxPro. În schimb, creați metode personalizate și apelați-le pe cele din metodele native. Nu există, desigur, nicio cerință să faci lucrurile în acest fel, dar îți va face viața mai ușoară din (din nou) trei motive:

• 	În primul rând, vă va permite să dați nume semnificative codului de metodă. Acest lucru poate suna banal, dar face întreținerea mult mai ușoară atunci când codul care „calculează taxa” este numit de ThisForm. CalcTax() ' mai degrabă decât ThisForm.CmdButtonl.Click()

• 	În al doilea rând, vă permite să schimbați interfața, dacă este necesar, prin simpla re-locare a unei singure linii de cod care apelează metoda în loc să fie nevoie să tăiați și să lipiți codul funcțional (cu toate posibilitățile de eroare pe care aceasta le presupune).

• 	În cele din urmă, vă permite să împărțiți codul complex în mai multe metode (și potențial reutilizabile). Codul din metoda asociată cu evenimentul acționează doar ca inițiator pentru codul dvs.
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Dar toate aceste lucruri de design funcționează cu adevărat în practică?

Ei bine, cu siguranță așa credem! Fișierele însoțitoare pentru acest capitol, în directorul CH03, includ un proiect care implementează conceptele de proiectare discutate mai sus. Figura 3.2 (mai jos) prezintă fila Classes a proiectului într-un stadiu incipient al dezvoltării bibliotecilor de clase. Chiar dacă este doar parțial construită, structura de bază este deja clară.

Figura 3.2 Exemplu de structură de clasă

Vom avea mai multe de spus despre convenția de denumire mai târziu. Pentru moment, ne uităm aici la structura clasei. Ceea ce vedeți este începutul bibliotecilor noastre de clasă „generice”. După cum sugerează și numele, aceste biblioteci conțin clase care nu conțin nicio funcționalitate specifică aplicației și sunt de fapt controalele „standard” pe care le-am creat.

Biblioteca RootClas.vcx

Prima bibliotecă (cel mai jos nivel) din structura noastră se numește RootClas.vcx și aceasta conține subclasele de primul nivel ale controalelor de clasă de bază VFP. Este o bibliotecă abstractă (singura funcție a acestor clase este de a fi părinte pentru alte clase) și clasele din această bibliotecă nu sunt, prin urmare, niciodată instanțiate direct. În același mod, singurele clase care sunt adăugate vreodată la această bibliotecă sunt clasele abstracte de „primul nivel”. Această regulă îndeplinește două funcții:

• 	Oferă un strat „izolant” între clasele noastre și clasele de bază VFP. În cazul în care o nouă ediție a VFP modifică valorile implicite sau comportamentul clasei de bază, codul existent poate fi corectat pur și simplu prin schimbarea clasei rădăcină corespunzătoare.

• 	Se asigură că setările standard (și orice proprietăți și metode personalizate care sunt adăugate la clasa rădăcină) sunt disponibile pentru toate clasele descendente. Schimbările în clasa rădăcină se vor reflecta, prin definiție, în toate clasele bazate pe acestea.

Biblioteca GenForms.vcx

Următoarea bibliotecă este o bibliotecă funcțională, folosită pentru a conține clasele noastre de formulare. Motivul pentru care le împărțim într-o bibliotecă proprie este pur și simplu pentru a nu primi clase de formular care aglomerează Bara de instrumente Controls. Una dintre multele îmbunătățiri pentru dezvoltatori, pe care le-a introdus VFP 6.0, a fost o extensie a comenzii CREATE FORM care vă permite să specificați clasa din care urmează să fie creat noul formular. În timpul dezvoltării, nu mai este nevoie să modificați setarea „Opțiuni de formular” sau să creați un set de formulare, să adăugați un formular din clasa necesară și să ștergeți clasa de bază furnizată implicit și așa mai departe. Această comandă face acum treaba:

CREATE FORM mynewForm AS xFrmStd FROM genforms

Toate clasele din această bibliotecă descind în cele din urmă din clasa rădăcină „xFrm”. Apropo, în convenția noastră de denumire, numele unei clase indică întotdeauna descendența acesteia (acest lucru se realizează prin denumirea acesteia cu un sufix la numele clasei din care derivă). Ne place acest lucru pentru că asigură că atunci când o bibliotecă este listată în ordine alfabetică (ca în managerul de proiect sau în dialogul Modificare clasă), acestea sunt, de asemenea, în ordine de moștenire. Deci, dacă ar fi să adăugăm o nouă clasă de formulare „Date” la această bibliotecă bazată pe clasa de formular „standard”, aceasta ar fi numită „xFrmStdData” și ar apărea în lista imediat sub clasa „xFrmStd”.

Acesta este un punct important deoarece nu există niciun motiv pentru care toate clasele dintr-o bibliotecă ar trebui să fie la același nivel de moștenire, dar este util să putem distinge, dintr-o privire, exact unde se află o anumită clasă în ierarhia ei.

Biblioteca GenClass.vcx

Această bibliotecă conține toate clasele noastre „generice” și este biblioteca care, implicit, este încărcată în bara de instrumente Form Controls de către VFP la pornire (vezi mai jos pentru detalii despre cum să se întâmple acest lucru). Clasele din această bibliotecă sunt pe care le folosim pentru a ne crea obiectele. Convenția noastră este că fiecare control din biblioteca Root Class are o versiune „Std” în biblioteca GenClass, care este baza pentru toate subclasele ulterioare și este versiunea „standard” a controlului pe care îl folosim atunci când creăm controale compuse.

În unele cazuri, clasa standard este de fapt o simplă copie a clasei rădăcină, în timp ce în altele clasa standard poate introduce funcționalitate suplimentară pe care am proiectat-o ca fiind aplicabilă tuturor claselor viitoare. De exemplu, clasa noastră standard de butoane de comandă are o nouă metodă personalizată adăugată la ea numită OnClick. Metoda nativă de clic VFP a fost modificată astfel încât, în mod implicit, apelează pur și simplu metoda OnClick, unde va fi plasat tot codul nostru la nivel de instanță.

Chiar dacă mai târziu ne răzgândim și descoperim că avem nevoie de o clasă care să nu includă o astfel de funcționalitate suplimentară, nu suntem complet pierduți pentru că pur și simplu putem folosi clasa noastră rădăcină ca părinte pentru o nouă ierarhie de moștenire.
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Cum se traduce de fapt designul în cod?

Dacă te uiți la clasa barei de navigare (da, în sfârșit revenim la ea), vei vedea că am construit-o astfel încât tot ceea ce fac butoanele de comandă este să apelăm la metoda Navigate a containerului părinte din metoda lor OnClick. Acest lucru este conform principiului că un obiect trebuie doar să știe cum să facă ceva fără să știe de fapt ce cod este implementat, care, în acest caz, a fost implementat prin utilizarea delegației. Toate butoanele pot avea acum același cod în metoda lor OnClick (și este doar o linie), deși fiecare trec un parametru diferit, așa cum se arată:

Primul buton: This.Parent.Navigate('PRIMUL')

Butonul Prev: This.Parent.Navigate('ANTERIOR')

Butonul următor: This.Parent.Navigate( 'NEXT' )

Ultimul buton: This.Parent.Navigate( 'ULTIMUL' )

Metoda Container's Navigate este locul în care se realizează cea mai mare parte a muncii și este locul în care se află codul real care mută indicatorul de înregistrare. Deși aceasta este o metodă a clasei barei de navigare, codul nu depinde de nimic altceva decât să i se transmită un parametru care indică tipul de navigare necesar și astfel va funcționa la fel de bine indiferent dacă este apelat de la unul dintre butoanele conținute sau de la altul, extern. , obiect:

LPARAMETRI tcMoveTo

LOCAL lcMoveTo, lcNewPos, lnRec

DACĂ VARTYPE(tcMoveTo) # „C” SAU EMPTY(tcMoveTo)

RETURNARE .F.

ENDIF

lcMoveTo = UPPER(ALLTRIM (tcMoveTo) )

lcNewPos = 'MID'

*** Acum putem procesa parametrul

FACE CAZ

CASE lcMoveTo = „URMĂTOR”

*** Treceți la următoarea înregistrare

OCOLIRE

IF EOF()

*** Oricum eram pe ultimul record

MERGE JOS

*** Setați indicatorul de poziție în consecință

lcNewPos = „ULTIMUL”

ALTE

*** Ne-am mutat LA ultima înregistrare

lnRec = RECNO()

OCOLIRE

IF EOF()

*** Da, am făcut-o, setați steag de poziție

lcNewPos = „ULTIMUL”

ENDIF

GO lnRec

ENDIF

CASE lcMoveTo = „ANTERIOR”

*** Accesați înregistrarea anterioară

SKIP -1

IF BOF()

*** Oricum eram pe primul record

MERGI SUS

*** Setați indicatorul de poziție în consecință

IcNewPos = „PRIMUL”

ALTE

*** Ne-am mutat LA Prima înregistrare

lnRec = RECNO()

SKIP -1

IF BOF()

*** Da, am făcut-o, setați steag de poziție

lcNewPos = „PRIMUL”

ENDIF

GO lnRec

ENDIF

CASE lcMoveTo = „ULTIMUL”

*** Trec la ultima înregistrare, așa că fă-o și setează steag

MERGE JOS

lcNewPos = „ULTIMUL”

CASE lcMoveTo = „PRIMUL”

*** Mergeți la Prima înregistrare, așa că faceți-o și setați steag

MERGI SUS

lcNewPos = „PRIMUL”

IN CAZ CONTRAR

*** Avem un parametru nevalid! În acest exemplu

*** Pur și simplu îl vom ignora și vom abandona mișcarea

*** dar returnați un „.F.” în cazul în care această metodă este

*** sunat extern!

RETURNARE .F.

ENDCASE

Observați că instrucțiunea case este ordonată astfel încât metodele Next/Prior să fie înaintea Ultimul/Primul. În Visual FoxPro, viteza de execuție a unei instrucțiuni do case depinde de poziția relativă a instrucțiunii care va fi executată. Este probabil ca acest cod să fie apelat cel mai des pentru navigarea cu un singur pas decât pentru sărituri, așa că aceste opțiuni sunt plasate pe primul loc. Este, în acest exemplu, un punct mic, dar care merită să vă obișnuiți să faceți.

De asemenea, am adoptat o strategie de atribuire a unei variabile locale care indică plasarea pointerului de înregistrare în tabel după navigare (lcNewPos). Acesta a fost inițializat la „MID” - mijlocul tabelului fiind rezultatul cel mai probabil într-o aplicație care rulează. Această valoare este apoi transmisă unei alte metode de container care se ocupă de activarea și dezactivarea butoanelor pe baza valorii pe care o primește:

*** Apelați metoda SetButtons pentru activare/dezactivare

*** Dar mai întâi dezactivați ecranul!

ThisForm.LockScreen = .T.

This.SetButtons( lcNewPos )

*** Apelați metoda RefreshParent pentru a actualiza afișajul

This.RefreshParent()

*** Reactivați ecranul

ThisForm.LockScreen = .F.

*** Orice metodă returnează .T. implicit, deci nu este cu adevărat necesar

*** dar este util atunci când parcurgeți codul, deoarece permite a

*** Punct de întrerupere care trebuie setat pentru a verifica valorile

RETURNARE .T.

Responsabilitatea finală (reîmprospătarea formularului părinte) este gestionată de o altă metodă container, metoda RefreshParent. Prin împărțirea funcționalității astfel, putem gestiona diferite metode de navigare (în schimb, apelarea metodelor de formulare, de exemplu), pur și simplu suprascriind metoda Navigate atunci când este necesar. În mod similar, putem schimba comportamentul butonului sau comportamentul de reîmprospătare, fără a afecta nimic altceva.

Acest ultim punct este foarte important. Dacă examinați metoda RefreshParent, veți observa că se referă în mod explicit la ThisForm:

*** Această metodă reîmprospătează formularul părinte pentru Bara de navigare

*** Dacă avem o metodă RefreshForm, apelați-o, altfel folosiți Refresh nativ

IF PEMSTATUS( ThisForm, 'RefreshForm', 5 )

ThisForm.RefreshForm()

ALTE

ThisForm.Refresh()

ENDIF

Aceasta nu este o presupunere nerezonabilă, deoarece pentru a face un obiect vizibil în Visual FoxPro, acesta trebuie să fie conținut fie într-un formular, fie într-o bară de instrumente, iar aspectul vizual al acestui control, așa cum îl avem acum, îl face inadecvat pentru o bară de instrumente în formatul actual.

Crearea unei subclase pentru utilizare într-o bară de instrumente

Pentru a crea o bară de navigare care ar fi potrivită pentru o bară de instrumente, putem pur și simplu subclasa acest control și suprascrie metoda RefreshParent din subclasă pentru a utiliza forma de referință mai adecvată unei bare de instrumente (adică Screen.ActiveForm, în loc de ThisForm). O astfel de subclasă este inclusă în proiectul CH03 și veți observa că, în afară de schimbarea aspectului clasei, singurul cod care a trebuit să se schimbe este metoda unică care se ocupă cu reîmprospătarea care acum arată astfel:

*** Această metodă suprascrie comportamentul clasei părinte care reîmprospătează formularul

*** Și folosește Screen.ActiveForm în schimb

CU Ecran.ActiveForm

IF PEMSTATUS( _Screen.ActiveForm, 'RefreshForm', 5 )

. RefreshForm ( )

ALTE

.Reîmprospăta()

ENDIF

SE TERMINA CU

O posibilă „înțelegere” aici apare atunci când utilizați formulare cu Private DataSessions. Orice bară de instrumente care se bazează pe _Screen.ActiveForm pentru a accesa datele asociate cu acel formular trebuie să se asigure că se comută mai întâi în aceeași sesiune de date. Acest lucru nu este atât de simplu pe cât ar putea părea la prima vedere, deoarece o bară de instrumente nu poate primi focalizare. Cu toate acestea, puteți utiliza următorul cod în metoda MouseMove pentru a rezolva problema:

IF TYPE ( "_Screen.ActiveForm" ) = "O" ȘI ! ISNULL(_Screen.ActiveForm)

This.DataSessionId = _Screen.ActiveForm.DataSessionId

ENDIF

Alte extensii ale clasei

O altă extensie utilă la această clasă ar fi adăugarea unui comportament astfel încât să ajusteze automat setările butonului atunci când este inițializat și poate ori de câte ori formularul în care se află este reactivat. Pentru a face acest lucru, am adăuga o altă metodă personalizată (poate că CheckRecPointer ar fi un nume potrivit). Aceasta ar determina dacă indicatorul de înregistrare se află la prima, ultima sau la o înregistrare intermediară și ar apela metoda SetButtons cu parametrul corespunzător. Noua metodă ar putea fi apoi apelată din Init-ul containerului în sine pentru a gestiona inițializarea și printr-un eveniment extern, cum ar fi un formular Activate sau o bară de instrumente MouseMove pentru a forța o actualizare de stare.

Concluzie

Acest exemplu, deși trivial în detaliu, arată cât de important este designul în mediul orientat obiect. Designul final al acestui control este departe de abordarea „tradițională” în care codul pentru mutarea indicatorului de înregistrare ar fi fost plasat direct în butoane. Secretul unui design bun constă de fapt în a determina de ce este cu adevărat responsabilă fiecare componentă din clasă. Astfel, în exemplul barei de navigare de mai sus, responsabilitatea reală a butoanelor este să recunoască faptul că utilizatorul dorește să navigheze într-un anumit mod și să comunice acest fapt operatorului corespunzător. Aceste butoane nu trebuie să fie responsabile pentru a face altceva și, prin urmare, nu ar trebui să FACĂ nimic altceva!
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Lucrul cu clasele tale

Odată ce ați definit clasele, veți dori, desigur, să începeți să le utilizați în munca de zi cu zi, în loc să piratați pur și simplu clasele de bază Visual FoxPro „după cum este necesar”. Pentru a face acest lucru eficient, trebuie să puteți instrui FoxPro când să vă folosiți clasele în loc de valorile implicite standard furnizate cu produsul.

Cum îmi introduc clasele în bara de instrumente Controls formular?

Bara de instrumente Form Controls afișează în orice moment conținutul unei biblioteci de clasă și, implicit, deschide Clasele de bază VFP ca „Standard”. Pentru a schimba ceea ce este afișat, selectați pictograma bibliotecă din bara de instrumente Form Controls (Figura 3.3).

Figura 3.3 Pictograma „Bibliotecă” din bara de instrumente Form Control

Aceasta va afișa un meniu pop-up care arată toate bibliotecile disponibile în prezent, pe care le puteți selecta și actualiza și care vă permite, de asemenea, să adăugați o bibliotecă suplimentară la bara de instrumente.

Figura 3.4 Fereastra pop-up Add Class Library

Intrările pentru „Standard” și „Controale ActiveX” sunt întotdeauna prezente. Puteți adăuga una sau mai multe biblioteci la această listă ca parte a procedurii de pornire a Visual FoxPro, specificând fișierele bibliotecii necesare în fila Controale din dialogul Opțiuni VFP. Orice biblioteci definite aici sunt stocate în Registry sub cheia:

HKEY CURRENT_USER\Software\Microsoft\VisualFoxPro\6.0\Options\VCXList

În timp ce lista de biblioteci de încărcat este stocată în Registry, biblioteca pe care ați folosit-o ultima dată este de fapt stocată în fișierul de resurse. Deci, dacă doriți să vă păstrați setarea între sesiunile FoxPro, trebuie să aveți SET RESOURCE ON.

То modificați biblioteca care va fi afișată, deschideți pur și simplu fie formularul, fie designerul de clasă, selectați biblioteca pe care doriți să o actualizați și apoi salvați modificarea când închideți designerul. Data viitoare când deschideți designerul, ultima bibliotecă folosită va fi în bara de instrumente pentru dvs.

În timp ce suntem la asta, cum îmi pot identifica clasele personalizate în bara de instrumente?

Toate clasele au două proprietăți (care pot fi accesate prin intermediul casetei de dialog Informații despre clasă selectând pad-ul Class din meniu în timp ce sunteți în Designerul de clasă) denumite „Pictogramă Container” și „Icon bara de instrumente”. Prima se referă la pictograma care apare lângă numele clasei în Managerul de proiect. Al doilea se referă la pictograma care va fi afișată în bara de instrumente Form Controls. VFP se așteaptă la o dimensiune a imaginii de 16 x 16 pixeli pentru aceste pictograme și, în ciuda faptului că le este numită „pictograme”, va accepta fie formatul Icon, fie format BMP pentru afișare.

Barei de navigare din biblioteca de clase СНОЗ.ѵсх i-au fost atribuite hărți de biți separate pentru cele două proprietăți. Motivul pentru care aveți nevoie de două este că fundalul pentru pictograma barei de instrumente este gri deschis, dar pentru pictograma container trebuie să fie albă.

Deci, este destul de ușor de făcut, dar crearea unor imagini suficient de distinctive și memorabile s-a dovedit mai dificilă și mărturisim că avem tendința de a rămâne cu pictogramele VFP standard, cu excepția cazului în care există un motiv covârșitor de bun pentru a face altfel. La urma urmei, numele clasei este afișat automat în sfatul cu instrumente pentru fiecare buton din bara de instrumente Controls și descoperim că acesta este de obicei suficient pentru nevoile noastre. (Deși unul dintre elementele din lista noastră de dorințe este că sfatul instrument va afișa descrierea clasei, mai degrabă decât numele, dacă este disponibil unul.)

În Visual FoxPro Versiunea 5.0 și versiunile ulterioare, afișarea „pictogramei Container” a unei clase în managerul de proiect este controlată de setarea unei casete de selectare în fila Proiect din dialogul Opțiuni global. Intrarea din fișierele de ajutor despre pictogramele containerului nu menționează această informație destul de vitală.

Dar ori de câte ori vreau alb în bitmaps-ul meu apare gri!

Una dintre micile ciudate iritante ale Windows este că interpretează albul într-un fișier bitmap sau pictogramă ca fiind transparent și afișează, în schimb, culoarea implicită de fundal. Pentru a preveni acest lucru, trebuie să creați un fișier „mască” pentru fiecare bitmap care utilizează alb, în care toate zonele pe care doriți să le vedeți ca albe în bitmap-ul prezentat sunt colorate în negru. Acest lucru se face cel mai bine prin modificarea bitmap-ului original și salvarea acestuia cu o extensie „.MSIC în același director. Figura 3.5 arată cum arată de fapt hărțile de bit și fișierele masca pe care le-am folosit pentru exemplul nostru de bară de navigare.

TBNavbar.bmp

CNNavbar.msk

CNNavbar.bmp

Figura 3.5 Utilizarea unui fișier MSK pentru a afișa alb în hărți de bit

Fără fișierul mască, bitmap-ul „CNNavbar” ar arăta exact la fel ca bitmap-ul „TBNavbar”, dar cu fișierul mască va fi afișat corect. Puteți vedea rezultatul în fila Clasa proiectului CH03.

Cum fac ca Visual FoxPro să-mi folosească clasele în loc de clasele de bază?

Visual FoxPro 5.0 a introdus funcționalitatea „intellidrop” care vă permite să definiți ce clase sunt utilizate pentru controalele care sunt create atunci când un câmp de date este tras într-un formular fie din fila DataEnvironment, fie din fila de date Project Manager. Există două moduri de a configura aceste informații.

Informațiile implicite pe care le utilizează VFP sunt stocate în Registry în cheia:

HKEY_CURRENT_USER\Software\Microsoft\VisualFoxPro\6.0\Options\IntelliDrop

Dacă nu există nimic în această cheie, atunci sunt utilizate clasele de bază VFP. Pentru a vă configura propriile clase ca implicite, puteți utiliza fila „Field Mapping” din caseta de dialog Opțiuni. Acest lucru vă permite să definiți ce clasă, din ce bibliotecă, să utilizați pentru controale pe baza tipului de date al câmpului (vezi Figura 3.6 de mai jos). Orice setări pe care le definiți aici vor fi salvate în registru și utilizate pentru toate tabelele în mod implicit.

Dacă utilizați un container de bază de date, aveți o altă modalitate de a configura intellidrop care va suprascrie orice setări implicite câmp cu câmp. În Designerul de tabele pentru tabele legate există o secțiune „Map field type to classs” unde puteți defini clasa și biblioteca care vor fi utilizate ori de câte ori un anumit câmp este tras pe un formular. Aceasta anulează orice setare implicită și este utilă atunci când aveți un câmp în care clasa care trebuie utilizată depinde de conținutul real, mai degrabă decât de tipul de date (de exemplu, este posibil să aveți o clasă specială de casetă de text ZipCode care ar trebui utilizată oricând un ZipCode este necesară).

Figura 3.6 Dialog de cartografiere a câmpurilor pentru setarea claselor implicite I nielli Drop

Cum schimb legenda etichetei pe care o adaugă VFP?

Când trageți un câmp într-un formular (sau în designerul de clasă) fie din mediul de date, fie din managerul de proiect, comportamentul implicit al intellidrop este de a adăuga o etichetă a cărei legendă este numele câmpului. Aceasta este singura opțiune disponibilă pentru un tabel gratuit, dar pentru tabelele care fac parte dintr-o bază de date există câteva setări suplimentare care pot fi făcute.

Din nou, fila Maparea câmpurilor din dialogul Opțiuni oferă mecanismul pentru setarea comportamentelor implicite. Observați casetele de selectare de la subsolul acestui dialog - sunt patru dintre ele.

• 	Trageți și plasați subtitrarea câmpului: Când este bifată, Visual FoxPro va adăuga o etichetă (din orice clasă ați definit-o) la fiecare câmp atunci când este tras și setează legenda sa la „Caption” definită în designerul de tabel pentru acel câmp. Dacă nu există nicio legendă definită sau tabelul este un tabel „liber”, numele câmpului va fi inserat. Pentru a preveni adăugarea automată a unei etichete, debifați această casetă.

• 	Comentariu câmp Сору: Fiecare control are o proprietate „Comentariu”. Când această opțiune este bifată, conținutul proprietății „Comentariu” a câmpului este inserat în proprietatea „Comentariu” a controlului țintă.

• 	Сору field input mask: Se asigură că orice mască de intrare care a fost definită în baza de date este copiată în proprietatea InputMask a controlului inserat.

• 	Format câmp Сору: Se asigură că orice format care a fost definit în baza de date este copiat în proprietatea Format a controlului inserat.

Când lucrați cu tabele legate (cele care fac parte dintr-un container de bază de date), Table Designer oferă posibilitatea de a seta toate elementele de mai sus la nivel de câmp individual. Acestea sunt extrem de utile

și, oricum, din experiența noastră, este subutilizat de către dezvoltatori. Ca parte a designului bazei de date, ar trebui să setați întotdeauna proprietățile Caption și Comment ca minim.

Singurul dezavantaj este că Caption este folosit și de Visual FoxPro pentru Grid Header (care este util) și în ferestrele Browse (care, dacă tu, ca noi, tindeți să utilizați o linie de comandă navigați pentru a verifica numele câmpurilor nu este atât de util). Poate fi vorba de comportamentul din urmă, pentru care nu există nicio modificare, ceea ce explică de ce atât de mulți dezvoltatori par reticenți în a folosi capacitățile la nivel de câmp oferite.

Deci, pot obține o căutare pentru a afișa numele câmpului atunci când este setată o legendă?

Ei bine, de fapt, puteți, deoarece în Visual FoxPro, fereastra de navigare se întâmplă să fie un obiect grilă! Încercați acest cod din linia de comandă:

UTILIZAȚI clienți

RAUSCĂ NUMELE o Răsfoiește ACUM Așteptați

*** Minimizați fereastra de navigare (pentru a putea vedea ecranul)

AFIȘAȚI MEMORIA CA OB*

Rezultatul va fi:

REZULTATE Pub O GRID

Deci, dacă aveți nevoie să puteți răsfoi un tabel și să vedeți numele câmpurilor, tot ce aveți nevoie este un mic program „decorator” pentru a îmbunătăți comanda standard BROWSE. Următorul program face exact asta și ar putea fi un candidat pentru fișierul dvs. de procedură „Mediul de dezvoltare” (sperăm că nu ar avea nicio valoare în timpul execuției!):

**************************************************** ********************

* 	Program.BrowExt.prg

* 	Compiler...:Visual FoxPro06.00.8492.00 pentru Windows

* 	Rezumat...:Decorator pentru comanda standard de Răsfoire care restaurează

* 	...........:numele câmpului în locul legendei din fereastra de răsfoire

**************************************************** ********************

*** Această versiune funcționează numai în VFP5 sau o versiune ulterioară

LnCnt LOCAL

RAUȚIȚI NUMELE o Răsfoiți ACUM Așteptați

PENTRU FIECARE loc în oBrowse.Columns

loCol.Headerl.Caption = PROPER( SUBSTR(loCol.ControlSource, ;

RAT('.',loCol.ControlSource)+1 ))

URMĂTORUL
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Design interfață utilizator

Până acum ne-am concentrat asupra unora dintre problemele cheie în proiectarea și lucrul cu clasele. Cu toate acestea, designul interfeței dvs. de utilizator este, în cele din urmă, și mai important, dacă doar pentru că pentru utilizatorii finali, interfața de utilizare este de fapt aplicația. De fapt, utilizatorii seamănă cu obiectele prin aceea că rareori, sau vreodată, au nevoie să știe cum se face ceva, doar unde să meargă pentru a-l face! Prin urmare, principiile care guvernează proiectarea interfeței dvs. de utilizator nu sunt diferite de cele pe care le-am expus deja pentru proiectarea cursurilor.

În această secțiune nu ne vom opri asupra unor probleme de bază precum utilizarea fonturilor, culorilor și plasarea etichetelor, casetelor de text și a altor comenzi. Presupunem că aveți deja, sau veți adopta, un set de standarde pentru a decide astfel de chestiuni. În schimb, dorim să încercăm să acoperim unele dintre problemele mai puțin evidente care, prea des, sunt implementate prost, dacă nu incorect.

Percepția guvernează acceptarea

Prima, și probabil cea mai importantă problemă, este că de cele mai multe ori utilizatorii finali vă vor judeca aplicația după performanța percepută. Dacă o aplicație este intuitivă și ușor de utilizat, arată și se simte rapid și receptiv, atunci este probabil să fie bine acceptată chiar dacă nu face lucrurile exact în modul în care oamenii se așteptau inițial. În schimb, dacă aplicația dvs. este văzută ca fiind „dificil” de utilizat, lentă sau nu răspunde, atunci utilizatorii sunt mai puțin probabil să o accepte - chiar dacă face exact ceea ce s-a dorit exact în modul în care a fost solicitat. Deci, cum vă puteți asigura că aplicația dvs. nu transmite o percepție greșită?

Faceți ceva să se întâmple imediat!

Prima regulă de aur este să vă asigurați că ceva se întâmplă imediat ce utilizatorul interacționează cu aplicația dvs. Interfața Microsoft Windows 95/98 are un exemplu excelent al acestui principiu. Făcând clic pe butonul „Start”, în aproape orice situație, se va afișa imediat întregul „meniu de pornire” de primul nivel. Bineînțeles că poate dura câteva secunde, în funcție de ceea ce face sistemul, pentru ca o selecție din acel meniu să fie executată - dar nu acesta este ideea. Cheia este că există un răspuns instantaneu.

Din păcate, prea des am văzut aplicații în care un utilizator dă clic pe un buton și după câteva secunde apare o fereastră de mesaj care spune „Working... .Please Wait”. Desigur, până în acest moment, utilizatorul a mai făcut clic pe butonul de mai multe ori și acum a blocat întreaga aplicație timp de câteva ore, făcând ca același proces lung să ruleze de o jumătate de duzină de ori consecutiv. (Utilizatorii chiar cred că uneori sistemul nu „aude” clicul?) Soluția obișnuită pare să fie „Ctrl+Alt+Delete!”

Desigur, există situații, în special în aplicațiile de rețea sau client/server, când va exista o întârziere în timpul recuperării datelor, dar acesta nu este un motiv pentru a nu oferi utilizatorului un feedback imediat. O soluție bună la această problemă specială este de a face butonul de comandă să se dezactiveze imediat după un clic. Acest lucru realizează două lucruri - oferă un indiciu vizual că s-a întâmplat ceva și, mai important, îl împiedică pe utilizator să declanșeze din greșeală procesul de mai multe ori făcând clic din nou pe buton. Clasa „xCmdStdDisable” din biblioteca CH03.VCX se bazează pe clasa noastră standard de buton de comandă, dar înlocuiește metoda clic pentru a adăuga această funcționalitate:

Cu asta

.Activat = .F.

DODEFAULT()

.Activat = .T.

SE TERMINA CU

Desigur, dacă utilizați grafică pe butoanele de comandă, puteți chiar să specificați imagini diferite pentru fiecare dintre cele trei stări ale butonului pur și simplu setând proprietăți.

Tabelul 3.2 Proprietăți imagine pentru butonul de comandă

Funcția de proprietate	
Imagine 	Afișată când butonul este activ, dar nu este selectat
DownPicture 	Afișat când se face clic pe butonul și se ține apăsat
DisabledPicture 	Afișat când butonul este dezactivat

Tine utilizatorul la curent cu progresul

A doua regulă importantă este menținerea utilizatorilor informați cu privire la ceea ce face sistemul - mai ales dacă aplicația rulează un proces care durează o perioadă semnificativă de timp.. Cât de mult timp este semnificativ? Singurul răspuns real este că „depinde”. În mod normal, recomandăm ca orice lucru care depășește cinci secunde necesită un fel de informații, chiar dacă este doar o fereastră de așteptare, iar orice lucru care durează peste un minut ar trebui să aibă un fel de afișare a progresului.

Acest lucru ridică întrebarea ce fel de afișare a progresului ar trebui să utilizați? Abordarea standard Windows este de a folosi o „bară de termometru”. Am inclus un exemplu de clasă (ThermBar. VCX) și un program demonstrativ (ShoTherm.PRG) în exemplul de cod pentru acest capitol. Cu toate acestea, nu este singurul mecanism de afișare a progresului și, în anumite circumstanțe, nici măcar nu este cel mai bun. De exemplu, atunci când aveți un proces foarte lung sau în mai multe etape care nu progresează neapărat liniar în timp, o bară de termometru nu este de mare ajutor.

În astfel de situații, ne place să folosim o casetă cu listă, deoarece are avantajul major că un utilizator poate derula în sus și poate vedea ce s-a făcut și, astfel, să își facă o idee despre cum progresează procesul. Din nou am inclus o clasă exemplu (ListProg.VCX) și un program demonstrativ (ShoList.PRG) în codul acestui capitol.

Nu exagera cu raportarea progresului!

Există o avertizare în ceea ce privește raportarea progresului. Trebuie să vă asigurați că procesul de raportare a progresului nu are un impact semnificativ asupra procesului raportat. Prea mult este la fel de rău ca și prea puțin în acest sens și, în timp ce metodele „drăguțe” pentru a afișa progresul pot fi distractive de programat, ele pot deveni rapid iritante pentru utilizatorul final. Din nou, Microsoft a oferit un exemplu clasic - atunci când copiați fișiere în Windows Explorer, micile pagini care fluturează sunt amuzante prima dată când le vedeți, dar nu durează mult să vă dați seama că dacă utilizați o comandă DOS Copy, puteți copia mult fișierele. mai rapid decât Explorer. De ce asa? Răspunsul este că actualizarea continuă a afișajului de progres încetinește semnificativ procesul de copiere.

Menține-ți utilizatorii concentrați

Unul dintre cele mai frecvente defecte pe care le vedem în interfețele cu utilizatorul sunt ecranele care sunt pline de comenzi fără pixeli pătrați. Acest lucru înseamnă, de obicei, că ecranele se încarcă lent și aproape imposibil de lucrat cu excepția cazului în care se întâmplă să ai ochi ca un șoim pentru a observa cursorul printre masa de comenzi. În mod normal, motivul dat este că utilizatorii trebuie să vadă toate informațiile deodată și acest lucru poate prezenta unele probleme serioase pentru dezvoltator. Există, totuși, câțiva pași pe care îi puteți lua pentru a vă ajuta utilizatorii.

Selectați comenzile la intrare

Controalele editabile din Visual FoxPro au o proprietate SelectOnEntry despre care ați putea crede că ar asigura că ori de câte ori este selectat un control, (adică primește focus), întregul conținut al controlului va fi evidențiat ca „selectat”. Acesta este, evident, un lucru util de făcut, mai ales pe ecranele aglomerate, deoarece îi arată clar utilizatorului unde se află în prezent focalizarea. Fișierul de ajutor pentru SelectOnEntry afirmă că:

Specifică dacă textul dintr-o coloană celi, casetă de editare sau casetă de text este selectat atunci când utilizatorul trece la acesta. Disponibil în timpul proiectării și în timpul executării.

De asemenea, observă că numai controalele conținute în coloanele de grilă vor prezenta acest comportament în mod implicit. Observați totuși că textul folosește expresia „când utilizatorul trece la el”. Cu alte cuvinte, funcționează doar atunci când un control primește focalizare în virtutea poziției sale - NU funcționează atunci când utilizatorul face doar clic pe un control cu mouse-ul (nici soluția alternativă de setare a proprietății Format = „K”). Deci, trebuie să scrieți un cod dacă doriți o adevărată capacitate „Select On Entry”.

Cea mai bună soluție pe care am găsit-o este să folosim metoda GotFocus și, (în clasa dvs.) adăugați următorul cod:

TextBox::GotFocus()

Aceasta.SelStart = 0

This.SelLength = 999

NODEFAULT

Este posibil ca acest scop al acestui cod să nu fie evident până când nu vă amintiți că GotFocus este unul dintre evenimentele native care au un anumit comportament definit. O parte a acestui comportament nativ este, aparent, să setați atât SelStart, cât și SelLength la 0!

Deci, pentru ca codul nostru să funcționeze în toate circumstanțele, trebuie mai întâi să forțăm VFP să execute comportamentul clasei de bază „în afara secvenței”. (În mod normal, codul clasei de bază rulează după orice cod personalizat și avem nevoie de el, deoarece fără el, controlul nu se va concentra deloc!) Odată ce a fost făcut, putem seta proprietățile pentru a poziționa cursorul (SelStart) și pentru a adăugați evidențierea (SelLength) pentru a evidenția întregul conținut al controlului. În cele din urmă, trebuie să oprim executarea codului clasei de bază în locul său normal, așa că adăugăm o comandă nodefault. Clasa de casete de text xTxtStdSel (vezi biblioteca GenClass.VCX în codul pentru acest capitol) are acest comportament și va selecta corect tot textul, totuși utilizatorul acordă atenție unui control.

Folosiți sfaturi pentru a ajuta utilizatorii să lucreze cu formularul

Una dintre cele mai frumoase caracteristici ale Visual FoxPro este că toate controalele au o proprietate ToolTipText care se comportă ca toate celelalte sfaturi cu instrumente din Windows. Când treceți mouse-ul peste un control, sfatul este afișat după câteva secunde. Acest lucru nu este intruziv și apare doar atunci când utilizatorul „cere” de fapt. Mai important, acesta apare în locația indicatorului mouse-ului, spre deosebire de textul specificat de proprietatea StatusBarText care apare doar pe bara de stare. (Aceasta necesită ca aplicația dvs. să folosească o bară de stare și, prin urmare, este inutilă, cu excepția cazului în care aplicația dvs. rulează în ecranul principal VFP.)

Amintiți-vă - deși capacitatea de a avea un tooltip este o proprietate a unui obiect, capacitatea de a-l afișa este o proprietate a Formularului (sau a Barei de instrumente) pe care se află. Pentru a activa sfaturi cu instrumente, ar trebui să setați proprietatea ShowTips la true în clasa dvs. rădăcină atât pentru clasele Formular, cât și pentru Bara de instrumente.

Dar sfaturile instrumente NU sunt un substitut pentru ajutorul sensibil la context! Lungimea maximă permisă este de 127 de caractere (și chiar și asta este într-adevăr prea lungă!). Vă recomandăm să folosiți sfaturi pentru:

• 	Avertizarea utilizatorului că este necesară o introducere într-un câmp

• 	Specificarea faptului că controlul este limitat la un anumit tip de intrare

• 	Reamintirea utilizatorilor când există opțiuni suplimentare (de exemplu, meniuri cu clic dreapta)

Utilizați controlul potrivit pentru lucrare

Acest lucru poate părea evident, dar este uimitor de câte ori am auzit oameni spunând ceva de genul „Încerc să încarc o casetă combinată cu 13.000 de rânduri și este lent”. Ei bine, e o surpriză! Apropo, cum ar trebui să lucreze un utilizator cu o casetă combinată care, în toate versiunile de VFP anterioare versiunii 6.0, este limitată la un afișaj cu 7 rânduri, dar conține 13.000 de rânduri de date? Chiar și cu căutarea progresivă, aceasta este o combinație destul de descurajantă. Mai rău încă, o casetă combinată nu este un control ușor de manipulat în cel mai bun caz - o alunecare a mouse-ului și trebuie să o iei de la capăt.

Utilizați o grilă pentru liste lungi

Vom avea multe de spus despre mecanica predării controalelor listei în capitolul dedicat în mod special acestora, deocamdată dorim să ne concentrăm pe „când” mai degrabă decât pe „cum” ar trebui.

utilizati-le. Așadar, iată ghidul nostru ideal, deși recunoaștem că, în practică, poate fi necesar să îl încalci:

Pentru listele care conțin câteva ZECI de rânduri, un combo (sau listă) este în regulă, dar pentru orice altceva ar trebui să luați în considerare utilizarea unei grile numai pentru citire.

De ce să folosiți o grilă numai pentru citire? Motivul este că o grilă va încărca datele secvenţial, după cum este necesar, mai degrabă decât să fie nevoie să recupereze toate datele la iniţializare, ceea ce trebuie să facă o listă sau o casetă combinată. Trucul aici este să configurați o clasă grilă care să arate ca o listă obișnuită. Acest lucru este destul de simplu, doar setați câteva proprietăți pentru grilă (consultați clasa xGrdStdList din GenClass.VCXlibrary):

Număr de coloane = 1

AllowHeaderSizing = .F.

AllowRowSizing = .F.

DeleteMark = .F.

GridLines = 0

Înălțimea antetului = 0

ReadOnly = .T.

RecordMark = .F.

ScrollBars = 2

SplitBar = .F.

Apoi setați proprietatea mobilă la .F. pentru coloană.

Au fost adăugate câteva îmbunătățiri. Mai întâi am adăugat o proprietate nRows la clasă pentru a defini câte rânduri ar trebui să fie vizibile. Aceasta este folosită, în metoda Init a clasei, pentru a seta exact înălțimea grilei și pentru a evita „rândurile parțiale” inestetice care prea des strică aspectul grilelor. În al doilea rând, mărim și coloana vizibilă pentru a umple întreaga lățime a zonei de afișare (mai puțin lățimea barei de defilare verticală, desigur):

*** Setați Height la numărul exact de rânduri specificat în proprietatea nRows

This.Height = This.RowHeight * This.nRows

*** Forțați coloana să umple lățimea disponibilă

This.Columns[1].Width = This.Width - SYSMETRIC(7)

În cele din urmă, caseta de text a grilei include codul de selectare la intrare, pe care l-am explicat mai devreme, pentru a se asigura că atunci când un utilizator face clic pe grilă, „rândul” este evidențiat corespunzător. Cu toate acestea, deoarece caseta de text este într-o grilă, în loc să plaseze codul în caseta de text metoda GotFocus, trebuie să meargă în metoda Click!

În funcție de utilizarea dvs. pentru o clasă de listă lungă, va trebui să adăugați orice cod necesar și poate unele proprietăți și metode personalizate, dar comportamentul de bază este deja furnizat. Deoarece derularea într-o grilă va muta indicatorul de înregistrare în sursa sa de înregistrare, obținerea articolului selectat nu este o problemă - luați doar numărul de înregistrare (sau conținutul oricărui câmp doriți).

Cel mai important, deoarece grila poate folosi toate câmpurile din tabelul pe care îl căutați, nici măcar nu trebuie să specificați ce câmpuri aveți nevoie. Puteți chiar să utilizați un cursor (sau vizualizare) pentru a crea un subset de date din mai multe tabele.

Singura problemă este că poate fi necesar să utilizați o casetă combinată, mai degrabă decât o casetă listă, pentru a economisi spațiu pe un formular. Pentru a rezolva această problemă, am creat o clasă „combo-grid” care imită comportamentul

un combo, dar folosește o grilă în loc de lista verticală standard - consultați capitolul Combo și liste pentru detalii.

Un exemplu de utilizare a unui formular modal pentru a returna un ID de client selectat este inclus în exemplul de cod pentru acest capitol. Rețineți că pentru a seta evidențierea inițială, pur și simplu găsim înregistrarea dorită în metoda Init a formularului și setăm focusul pe grilă. Pentru a rula acest formular, pur și simplu faceți următoarele din fereastra de comandă (109 este pur și simplu o valoare cheie pentru tabel):

FORM frmGList CU 109 PENTRU IcSelectlon

? IcSelectlon

Figura 3.7 Clasa grdList în uz
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Capitolul 4 - Controale de bază

„Există o mare satisfacție în construirea unor instrumente bune pe care să le folosească alți oameni.”

(„Disturbing the Universe” de Freeman Dyson)

Majoritatea timpului necesar pentru proiectarea și dezvoltarea unei aplicații este petrecut creând interfața. O bibliotecă bine concepută de clase de control reutilizabile va reduce foarte mult cantitatea de muncă necesară pentru a crea această interfață. Moștenirea permite ca funcționalitatea comună să fie integrată în clasele dvs. o dată la nivelurile superioare ale ierarhiei claselor, lăsându-vă liber să vă concentrați asupra proceselor logice complexe ale aplicației dvs. specifice. În acest capitol, vom împărtăși câteva caracteristici interesante pe care le-am integrat în setul nostru de clase de bază. Veți găsi toate clasele descrise în biblioteca CH04.VCX.
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Ce înțelegem prin „de bază”?

S-ar putea să vă întrebați ce înțelegem prin controale „de bază”. În scopul acestui capitol, ne referim la controalele care formează majoritatea oricărei interfețe de utilizator. Aceasta include de obicei casete de text, casete de editare, rotative, butoane de comandă și altele asemenea. Toate controalele personalizate prezentate în acest capitol vor funcționa atunci când sunt aruncate pe un formular, pagină sau când sunt plasate într-un container. Cu toate acestea, nu se garantează că funcționează atunci când sunt plasate într-o rețea, deoarece rețelele impun cerințe diferite privind construcția comenzilor lor. Prin urmare, controalele personalizate pentru utilizarea în interiorul grilelor vor fi acoperite în capitolul 6 „Grile: comenzile neînțelese”. Grilele, în special grilele de introducere a datelor, sunt suficient de complexe încât le-am dedicat o întreagă secțiune exclusiv.
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casete de text (exemplu: CH04.VCX::txtBase)

Majoritatea controalelor din interfața dvs. se vor baza probabil fie pe casete de text, fie pe casete de editare. Sunt clare, înțelese chiar și de utilizatorii începători. Ele pot fi folosite pe măsură ce ies din cutie, dar nu posedă nimic mai mult decât cea mai de bază funcționalitate. De exemplu, pentru a face ca o casetă de text să își selecteze întregul conținut atunci când primește focalizare, ați putea doar să setați proprietatea SelectOnEntry la .T (sau setați proprietatea Format la „K”). De fapt, oricare dintre acestea va funcționa numai atunci când controlul primește focalizarea prin mișcare de la un alt control și nu va face nimic atunci când utilizatorul face clic cu mouse-ul în caseta de text. Din fericire, este destul de ușor să oferi tuturor casetelor de text această funcționalitate de bază prin introducerea acestui cod în metoda GotFocus a clasei standard de casete de text:

TextBox::GetFocus()

.SelStart = 0

.SelLength = 999

NODEFAULT

Deoarece aceasta este o clasă rădăcină, s-ar putea să vă întrebați de ce folosim linia Textbox::GotFocus() în loc să emitem doar un DODEFAULT(). Motivul este că în Visual FoxPro 5.0a, a existat o eroare în DODEFAULT() care a determinat executarea comportamentului clasei de bază Visual FoxPro după executarea codului în clasa părinte. Aceasta însemna că, dacă nu ai avut un NODEFAULT la sfârșitul metodei din subclasa, codul clasei de bază va fi executat de două ori. (Acest lucru se datorează faptului că, implicit, Visual FoxPro rulează orice cod personalizat pe care l-ați introdus într-o metodă și apoi rulează codul clasei de bază.) În Visual FoxPro 6.0, DODEFAULT() nu mai rulează codul clasei de bază decât dacă, desigur, , subclasa este direct descendentă din clasa de bază Visual FoxPro. Deci, în Visual FoxPro 6.0, comportamentul clasei de bază este garantat să se execute atunci când îl apelați direct cu operatorul de rezoluție a domeniului.

Ca de obicei, există mai multe moduri de a jupui o vulpe. Această singură linie de cod din metoda GotFocus() din caseta de text realizează același lucru ca și cele patru linii enumerate mai sus:

This.SetFocus()

Ne place că casetele noastre de text să fie selectate la intrare în mod implicit. Cu toate acestea, este posibil să preferați un comportament diferit. Pentru a oferi flexibilitate, executăm condiționat codul de mai sus numai dacă proprietatea SelectOnEntry a casetei de text este setată la true.

De asemenea, am adăugat o metodă personalizată SetInputMask la clasa noastră rădăcină a casetei de text, după cum urmează:

LOCAL lcAlias, lcField, lcType, laFields[1], ;

lnElement, lnRow, lcIntegerPart, lcDecimalPart

Cu asta

DACĂ ! EMPTY( .ControlSource )

IF EMPTY( .InputMask )

*** Setați doar masca de intrare pentru câmpurile numerice și de caractere

*** și verificați tipul de date al câmpului de bază, astfel încât noi

*** îl poate seta în mod corespunzător

lcType = TYPE( This.ControlSource )

IF INLIST(lcType, 'C', 'N' )

*** Analizați aliasul și numele câmpului din ControlSource

lcAlias = JUSTSTEM( .ControlSource )

lcField = JUSTEXT ( .ControlSource )

*** Nu încercați să verificați proprietățile suportului

câmp *** dacă suntem legați la o proprietate de formular

IF UPPER( lcAlias ) # 'THISFORM'

*** formatează câmpul dacă este caracter

IF lcType = 'C'

InputMask = REPLICATE('X', FSIZE(lcField, lcAlias) )

ALTE

AFIELDS(laFields, lcAlias)

lnElement = ASCAN(laFields, UPPER(lcField))

DACA lnElement > 0

lnRow = ASUBSCRIPT(laFields, lnElement, 1)

lcIntegerPart = REPLICATE('9', laFields[lnRow, 3] - ;

laFields [lnRow, 4] - 1)

lcDecimalPart = REPLICATE('9', laFields[lnRow, 4])

.InputMask = lcIntegerPart + '.' + lcDecimalPart

ENDIF

ENDIF

ENDIF

ENDIF

ENDIF

ENDIF

SE TERMINA CU

Acest cod pur și simplu setează o mască de intrare implicită pentru controalele legate care nu au nicio mască de intrare specificată dacă controlul este legat de date de caractere și numerice. În cazul datelor de caractere, utilizatorii sunt împiedicați să introducă mai multe caractere decât ar putea fi salvate în câmpul de bază, fără a restricționa, care pot fi acele caractere. Pentru câmpurile numerice, previne erorile de depășire numerică.

Întâmpinarea casetei de text

Probabil știți că nu puteți emite un apel către metoda SetFocus a unui control din metoda Valid a oricărui control din Visual FoxPro versiunea 5.0 și o versiune ulterioară. Acest lucru este perfect logic atunci când considerați că singurul scop al metodei Valid este acela de a determina dacă controlul ar trebui sau nu să-și piardă focalizarea. Pentru a păstra focalizarea într-un control atunci când validarea dvs. eșuează, puteți pur și simplu să emiteți un RETURN 0, care îi spune VFP că focalizarea trebuie să rămână în controlul curent. Cea mai bună modalitate de a trece explicit focalizarea către un alt control este să utilizați cod ca acesta în metoda LostFocus:

This.Parent.SomeControl.SetFocus()

NODEFAULT

Acest lucru funcționează bine, dar ar trebui să știți și că atunci când introduceți acest cod în metoda LostFocus a unei casete de text, metoda sa Valid va fi declanșată din nou ori de câte ori se execută. Aceasta nu este o problemă decât dacă aveți cod în metoda Valid care se bazează pe o singură execuție înainte ca caseta de text să piardă focalizarea (de exemplu, creșterea unui contor sau afișarea unei casete de mesaj).
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Clasa de etichetă a casetei de text (Exemplu: CH04.VCX::txtLabel)

Când trebuie să aveți o etichetă care poate fi legată de anumite date, ni se pare util să aveți o clasă de casete de text care arată și acționează ca o etichetă. Deoarece o etichetă nu are o reîmprospătare și o casetă de text are, este ușor să schimbați afișarea atunci când formularul este reîmprospătat. De asemenea, ne place ca etichetele noastre să fie justificate corect, așa că am configurat clasa noastră txtLabel pentru a face acest lucru în mod implicit. (Puteți seta la fel de ușor pe a dvs. să fie justificată la stânga sau la centru.) Singura limitare minoră a clasei noastre txtLabel este că, deși este suficient de ușor să furnizați taste rapide (prin adăugarea de cod la metoda de apăsare a tastelor), pur și simplu nu există mod de a indica care este de fapt tasta rapidă. Configurarea unei casete de text pentru a arăta și a acționa ca o etichetă este o chestiune simplă și implică modificarea valorilor implicite ale următoarelor proprietăți:

Aliniere = 1 - Dreapta

BackStyle = 0 - Transparent

BorderStyle = 0 - Nici unul

IntegralHeight = .T.

SpecialEffect = 1 - Simplu

StrictDateEntry = 0 - Liber

TabStop = .F.

Pentru a imita perfect comportamentul unei etichete, trebuie de asemenea să ne asigurăm că clasa noastră de casete de text modificată nu poate primi focalizare. Acest lucru se realizează prin adăugarea unei singure linii de cod la metoda sa When, astfel încât să returneze întotdeauna o valoare logică FALSE:

RETURNARE .F.
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Casetă text pentru dată (Exemplu: CH04.VCX::txtDate)

Caseta text de introducere a datei este un control foarte simplu, dar eficient. Utilizează proprietatea Format pentru a afișa data în orice format este specificat de setarea Windows Long Date a utilizatorului (Format = "YL"). Un cod simplu numit de la GotFocus și LostFocus forțează setările Century și Rollover la valori care sunt setate ca proprietăți de clasă și se asigură că utilizatorii care insistă să introducă date cu un secol din ultimele două cifre nu provoacă trimiterea de date nevalide în tabelele dvs. . (De asemenea, ne place această formă de afișare pentru date.)

Figura 4.1 Caseta text pentru introducerea datei

Tabelul 4.1 Proprietăți personalizate ale casetei de text pentru dată

Scopul proprietății personalizate	
nRollYear 	Setat la momentul proiectării și utilizat de metoda setCent personalizată pentru a seta anul de transfer
nCentury 	Setat la momentul proiectării și utilizat de metoda personalizată SetCent pentru a seta secolul
cCentWas 	Folosit intern de metoda personalizată SetCent pentru a salva valorile curente ale SET
	( „CENTURY”, SET(„CENTURY”, 1) și SET(„CENTURY”, 2)

SetCent este apelat din metoda GotFocus a casetei de text pentru a salva setările curente ale secolului și a le reseta folosind proprietățile nRollYear și nCentury ale controlului. Setările originale ale secolului sunt restaurate în metoda RestCent care este apelată din metoda LostFocus. Acest cod din metoda SetCent a controlului vă arată cum salvăm setările originale înainte de a folosi proprietățile personalizate pentru a le reseta:

LOCAL lcCentWas, IcCentury, IcRollOn, InRollYear, InCentury

Cu asta

*** Salvați setările curente

STORE '' LA lcCentWas, IcCent, IcRollOn

*** Century Pornit/Oprit

lcCentWas = PADL( SET('Century'), 3)

*** Secolul de bază

lcCentury = PADL( SET('Century',1), 2, '0' )

*** Anul de rulare

lcRollOn = PADL( SET('Century',2), 2, '0' )

*** Salvați ca șir de caractere

.cCentWas = lcCentWas + lcCentury + lcRollOn

*** Dacă avem un anumit an RollOver, folosiți-l, altfel implicit este curent

lnRollYear = IIF( !EMPTY( .nRollYear), .nRollYear, INT( VAL( lcRollOn )) )

*** Dacă avem un anumit Century, folosiți-l, altfel implicit este curent

lnCentury = IIF( !EMPTY( .nCentury ), .nCentury, INT( VAL( lcCentury )) )

*** Set Century și Rollover

SET CENTURY TO (lnCentury) ROLLOVER (lnRollYear)

*** Force Century On

PUNEȚI SECOLUL

SE TERMINA CU

Acest lucru pur și simplu salvează orice setări sunt în vigoare în prezent pentru Century și stabilește noi setări bazate pe proprietățile controlului. Acest lucru este util deoarece SET CENTURY este una dintre numeroasele setări care sunt incluse într-o sesiune de date și pot fi trecute cu vederea. În plus, deoarece fiecare control gestionează propria versiune a secolului, puteți configura mai multe controale cu secole de bază diferite și ani de rulare diferiți pentru a gestiona lucruri precum datele de naștere și datele de maturizare a poliței de asigurare pe același formular. Metoda RestCent restabilește setările originale la ieșirea din control:

LOCAL lcCentWas, lnCentury, lnRollOn

STORE '' LA lcCentWas

Cu asta

*** Citiți înapoi setările salvate

DACĂ ! GOL ( .cCentWas )

lcCentWas = ALLTRIM( SUBSTR( .cCentWas, 1, 3) )

lnCentury = INT( VAL( SUBSTR( .cCentWas, 4, 2) ))

lnRollOn = INT( VAL( SUBSTR( .cCentWas, 6, 2) ))

*** Setați Secolul la implicit

SET CENTURY &lcCentWas

*** Restabiliți setările originale

SETAT CENTURY TO (lnCentury) ROLLOVER (lnRollOn)

ENDIF

SE TERMINA CU
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Casetă text de căutare incrementală (Exemplu: CH04.VCX::txtSearch)

O casetă de text de căutare incrementală este un instrument extrem de util. Nu numai că poate fi folosit ca atare pentru a găsi elemente specifice de date într-un formular, dar poate fi, de asemenea, transformat într-o subclasă pentru utilizare în grile de căutare incrementală și alte controale compuse care necesită această funcționalitate. De exemplu, puteți utiliza această clasă pentru a construi un control care acționează ca indexul fișierului de ajutor (tastați într-o casetă de text și o casetă cu listă afișează cea mai apropiată potrivire).

Majoritatea casetelor de text de căutare incrementală pe care le-am văzut folosesc metoda KeyPress pentru a apela metode personalizate care gestionează apăsările de taste, manipulează proprietățile SelStart și SelLength ale casetei de text și efectuează căutarea. În versiunea noastră a clasei, numim aceste metode din metoda InteractiveChange. Deoarece InteractiveChange se declanșează după KeyPress, este mai ușor (și necesită mai puțin cod) să lăsăm KeyPress să gestioneze intrarea reală așa cum o face întotdeauna și apoi să facem ceea ce vrem să facem după aceea. De fapt, caseta noastră de text de căutare incrementală nu are deloc cod personalizat în metoda KeyPress. Singurul cod este în InteractiveChange, care apelează doar metoda personalizată HandleKey atunci când este necesar, după cum urmează:

*** Dacă tasta apăsată a fost un caracter imprimabil, un backspace sau ștergere

*** gestionați apăsarea tastei și căutați

DACĂ This.SelStart > 0

DACĂ ( LASTKEY() > 31 ȘI LASTKEY() < 128 ) SAU ( LASTKEY() = 7)

This.HandleKey()

ENDIF

ENDIF

Deci, ce funcționalitate necesită o casetă de text de căutare incrementală? Evident, ar trebui să caute în tabelul specificat o potrivire în câmpul specificat în timp ce utilizatorul îl introduce. De asemenea, ar trebui să optimizeze căutarea folosind o etichetă index, dacă este disponibilă. Pentru a îndeplini aceste cerințe, adăugăm câteva proprietăți personalizate la clasa noastră de casete text de căutare incrementală:

cAlias = Tabelul de căutat

cField = Câmpul de căutat

cTag = Eticheta de index (dacă există) de utilizat la căutare

Caseta de text ar trebui, de asemenea, să completeze automat intrarea casetei de text (la fel cum face umplerea rapidă a lui Quicken). Dar ar trebui să reîmprospăteze și controalele din containerul părinte după repoziționarea indicatorului de înregistrare în tabelul specificat? Poate, dar din nou nu întotdeauna. Deoarece această ultimă caracteristică este necesară numai în circumstanțe specifice, trebuie să adăugăm o proprietate logică pentru a determina când ar trebui să apară acest comportament. Proprietatea lRefreshParent este adăugată la clasă și setată implicit la true pentru a oferi această flexibilitate. Numai când lRefreshParent este adevărat, metoda noastră HandleKey va apela metoda RefreshParent a casetei de text:

LOCAL loControl

PENTRU FIECARE loControl ÎN This.Parent.Controls

IF loControl.name # Acest.nume

*** Asigurați-vă că controlul are o metodă de reîmprospătare!! !

*** Amintiți-vă, etichetele nu au o metodă de reîmprospătare!

IF PEMSTATUS( loControl, 'Reîmprospătare', 5 )

loControl.Refresh()

ENDIF

ENDIF

ENDFOR

În cele din urmă, o casetă de text de căutare incrementală trebuie, prin definiție, să fie un control nelegat. (Dacă ar fi legat, valoarea specificată de sursa de control ar fi schimbată cu fiecare apăsare a tastei.) Deci, avem nevoie de o modalitate de a reîmprospăta valoarea inițială atunci când utilizatorul navighează la o înregistrare nouă. Prin urmare, a fost adăugată o singură metodă Synchronize și este apelată din metoda Refresh. Aceasta face toate lucrările necesare:

LOCAL lnSelStart

Cu asta

*** Salvați punctul de inserare

lnSelStart = .SelStart

*** Actualizați valoarea casetei de text cu câmpul de bază

.Valoare = EVAL( .cAlias + '.' + .cField )

*** Resetați punctul de inserare și selectați restul textului

.SelStart = lnSelStart

.SelLength = LEN( ALLTRIM( .Value ) ) - lnSelStart

SE TERMINA CU

Restul codului din clasa noastră de casete de text de căutare incrementală rezidă în metoda HandleKey. În ciuda faptului că de fapt face cea mai mare parte a muncii, cantitatea de cod este surprinzător de mică. Vă recomandăm insistent ca metodele să fie foarte concentrate în ceea ce privește funcționalitatea lor. Vă permite să păstrați codul scurt, făcând sarcinile de depanare și menținere a clasei mult mai simple. Așa că acum, fără alte prelungiri, iată codul pe care ai vrut să-l vezi:

LOCAL lcSofar, lnSelect, lnSelStart, lnSelLength

Cu asta

*** Salvați punctul de inserare

lnSelStart = IIF( LASTKEY() # 127, .SelStart, .SelStart - 1)

Aici ne asigurăm că nu afișăm valori eronate în caseta de text dacă, de exemplu, utilizatorul face backspace după primul caracter din caseta de text, lăsându-l gol. Este posibil să preferați ca caseta de text să afișeze valoarea pentru prima înregistrare din tabelul căutat. Dacă da, aici trebuie să ne schimbăm comportamentul standard:

*** Gestionați o valoare goală în caseta de text

DACA lnSelStart = 0

.Valoare = ''

.SelStart = 0

PENTRU BAZUL ( .cAlias )

SKIP IN ( .cAlias )

ALTE

Acum pentru lucrurile importante! Trebuie să ne asigurăm că cursorul este poziționat la sfârșitul șirului de caractere tastat până acum de utilizator. Deci trebuie să obținem acel șir și să căutăm o potrivire în tabelul specificat de proprietatea cAlias a casetei de text. Căutarea folosește eticheta de index indicată în proprietatea cTag dacă

a fost specificat unul. În caz contrar, trebuie să folosească locate pentru a încerca să găsească o înregistrare care se potrivește. Întrucât comanda locate se limitează la zona de lucru curentă (și nu poate face referire la alta), trebuie să ne asigurăm că salvăm zona de lucru curentă înainte de a selecta cAlias, astfel încât să putem restabili starea de fapt după aceea:

*** Obțineți valoarea introdusă până acum

IcSofar = LEFT( .Value, lnSelStart )

.Valoare = lcSoFar

*** Folosiți seek pentru a găsi înregistrarea dacă a fost furnizată o etichetă

DACĂ ! GOL ( .cTag )

IF SEEK( UPPER( lcSoFar ), .cAlias, .cTag )

.Valoare = EVAL( .cAlias + '.' + .cField )

ENDIF

ALTE

*** În caz contrar, salvați zona de lucru curentă

*** înainte de a trece la tabelul specificat

lnSelect = SELECT ()

SELECTAȚI ( .cAlias )

*** Și localizați înregistrarea specificată

LOCATE FOR UPPER( ALLTRIM( EVAL (.cField ) ) ) ) = UPPER( lcSoFar )

DACA ESTE GASIT ()

.Valoare = EVAL( .cAlias + '.' + .cField )

ENDIF

*** Restaurați zona de lucru inițială

SELECTARE ( lnSelect )

ENDIF

ENDIF

În acest moment, fie am găsit înregistrarea dorită în cAlias, fie suntem la sfârșitul fișierului. Tot ce rămâne de făcut este să resetați corect porțiunea evidențiată a casetei de text și să reîmprospătați controalele din containerul părinte (dacă acest lucru a fost specificat prin setarea .lRefreshParent = .T.):

*** Dacă trebuie să reîmprospătăm containerul părinte, fă-o aici

IF .lRefreshParent

.RefreshParent()

ENDIF

*** Evidențiați porțiunea valorii după punctul de inserare

.SelStart = lnSelStart

lnSelLength = LEN( .Value ) - lnSelStart

DACA LnSelLength > 0

.SelLength = lnSelLength

ENDIF

*** Dacă am reîmprospătat controalele din containerul părinte,

*** sunt probleme de sincronizare de depășit

*** Chiar dacă .SelStart și .SelLength au valorile corecte,

*** caseta de căutare nu apare evidențiată corect fără această întârziere

=INKEY( .1, 'H' )

SE TERMINA CU

Observați comanda inkeyo aici și faceți-vă ceva timp pentru a citi comentariul de mai sus, dacă nu ați făcut-o deja. Această problemă nu este specifică casetei noastre de text de căutare incrementală, iar problemele de sincronizare ca aceasta nu sunt neobișnuite în Visual FoxPro. (Ne-am întâlnit și atunci când afișăm casete de listă cu selecție multiplă în care sunt evidențiate selecțiile anterioare. În acest caz, utilizarea inkeyo în reîmprospătarea formularului permite evidențierea corectă a casetei de listă.) Este interesant de remarcat că inkeyo comanda nu este necesară în codul de mai sus când lRefreshParent = .F. Acest lucru oferă sprijin pentru ipoteza că aceasta nu este altceva decât o problemă de sincronizare. Pauza scurtă permite Visual FoxPro să ajungă din urmă.
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Casetă de text numerică (Exemplu: CH04.VCX::txtNum și txtNumeric)

Visual FoxPro a moștenit unele deficiențe seriale în ceea ce privește introducerea datelor numerice de la strămoșii săi FoxPro. Nu este prea rău când este selectat întreg câmpul, iar numărul nu este formatat cu separatori. Cu toate acestea, problemele încep să apară atunci când punctul de inserare nu se află la începutul valorii afișate. Uneori, utilizatorul încearcă să tasteze numărul 10, dar tot ce poate introduce este 1 și, cu confirmarea activată, valoarea casetei de text devine 1 și cursorul trece la următorul câmp. Am văzut și problema inversă. Utilizatorul dorește să introducă 3, dar după ce a tastat 3 și a ieșit din control, numărul 30 este afișat în loc de 3 intenționat. Deci, ce poate face un dezvoltator Visual FoxPro pentru a ajuta?

Există câteva soluții pentru această problemă. Puteți crea o casetă de text numerică pentru a selecta întregul câmp și pentru a elimina orice separatori folosiți pentru a formata numărul. Acest cod din metoda GotFocus din caseta de text permite introducerea corectă a numărului:

Cu asta

*** Salvați masca de introducere

.cOldInputMask = .InputMask

*** Eliminați separatoarele din masca de intrare

.InputMask = STRTRAN( .cOldInputMask, 	'' )

*** Efectuați Visual FoxPro nativ GotFocus()

TextBox::GotFocus()

*** Selectați întregul câmp

.SelStart = 0

.SelLength = LEN( .cOldInputMask )

*** Nu lăsați comportamentul clasei de bază să resetați SelStart/SelLength

NODEFAULT

SE TERMINA CU

Deoarece trebuie să schimbăm inputMask din caseta de text pentru a realiza acest lucru, adăugăm o proprietate personalizată numită coldInputMask pentru a menține inputMask original alocat controlului. Vom avea nevoie de această proprietate în metoda LostFocus a casetei de text pentru a restabili formatarea astfel:

This.InputMask = This.cOldInputMask

Desigur, avem deja o clasă de casete de text care selectează corect întregul câmp în care îl introduceți sau faceți clic cu mouse-ul pe el. Caseta noastră de text pentru clasa de bază face acest lucru atunci când SelectOnEntry = .T. Deci, tot ce trebuie să facem este să ne bazăm caseta de text numerică pe caseta de text din clasa de bază, să setăm SelectOnEntry la true și să punem acest cod în metoda GotFocus:

Cu asta

*** Salvați masca de intrare originală

.cOldInputMask = .InputMask

*** Eliminați separatoarele din masca de intrare

.InputMask = STRTRAN( .cOldInputMask, 	'' )

*** Efectuați comportamentul clasei părinte

DODEFAULT()

SE TERMINA CU

Caseta de text numerică descrisă mai sus poate fi suficientă pentru dvs. Este ușor de creat, nu conține mult cod și rezolvă problemele pe care le implică introducerea corectă a datelor numerice. Dar nu ar fi mai frumos să existe o casetă de text numerică care să introducă stilul calculatorului de la dreapta la stânga? Am văzut mai multe exemple de astfel de casete de text și, în opinia noastră, toate suferă de același neajuns. Fie cursorul poate fi văzut intermitent spre stânga pe măsură ce caracterele apar din dreapta, fie nu există niciun cursor. Ambele soluții tind să facă lucrurile confuze pentru utilizator. Așa că ne-am propus să creăm cea mai bună casetă de text numerică Visual FoxPro. Și am descoperit foarte repede de ce nu există în prezent. A fost greu! Așa că sperăm că veți găsi acest lucru util, deoarece este rezultatul a prea multe ore și a prea mult sânge, transpirație și lacrimi. Nu numai că introduce stilul calculatorului, ci și cursorul este poziționat pe caracterul corect. Când valoarea din caseta de text nu este selectată, puteți chiar să ștergeți sau să introduceți cifre individuale în mijlocul numărului afișat în caseta de text.

Caseta de text numerică este un control simplu de utilizat. Aruncă-l pe un formular, pagină sau container și setează-i proprietatea ControlSource. Asta e tot! Nici măcar nu trebuie să setați InputMask decât dacă doriți ca controlul să fie nelegat, deoarece este capabil să se formateze singur atunci când este legat. Modul în care funcționează majoritatea casetelor de text numerice este prin schimbarea valorii într-un șir de caractere, manipularea șirului și a InputMask și apoi reconversia șirului într-o valoare numerică. Cu toate acestea, caseta de text numerică este de fapt un control nelegat (chiar dacă îl puteți configura ca și cum ar fi legat) și funcționează deoarece valoarea sa este de fapt un șir de caractere și este manipulată ca atare. Folosește cod personalizat pentru a-și actualiza ControlSource cu echivalentul numeric al șirului de caractere care este valoarea acestuia.

Acest exemplu este conceput pentru a funcționa fie nelegat, fie legat de un câmp dintr-un tabel, cursor sau vizualizare. Dacă trebuie să vă legați la o proprietate de formular, codul va avea nevoie de o mică modificare pentru a-l explica. Un exemplu despre cum să faceți acest lucru poate fi găsit în metoda UpdateControlSource a clasei spnTime descrisă mai târziu în acest capitol.

Următoarele, opt proprietăți personalizate au fost adăugate casetei noastre de text numerice personalizate. Toate sunt folosite intern de control și nu trebuie să faceți nimic cu ele în mod explicit.

Tabelul 4.2 Proprietăți personalizate ale casetei de text numerice

Descrierea proprietății	
CcontrolSource 	Salvează ControlSource dacă acesta este un control legat înainte de a fi nelegat în metoda Init
Cfield 	Numele câmpului porțiune din ControlSource dacă este legat
CinputMask 	Stochează inputMask original atunci când este specificat, în caz contrar stochează inputMask construit de control
	

ColdConfirm 	Setarea originală a SET('CONFIRM') salvată în GotFocus, astfel încât să poată fi restaurată în LostFocus.
ColdBell 	Setarea originală a SET('BELL') salvată în GotFocus, astfel încât să poată fi restaurată în LostFocus
Cpoint 	returnat de SET('POINT')
Cseparator 	Caracter returnat de SET('SEPARATOR')
Ctable 	Porțiunea numelui tabelului din ControlSource dacă este legată
LchangingFocus 	Flag setat pentru a suprima TASTATURA „{END}”, care este folosită pentru a poziționa cursorul în poziția cea mai din dreapta în caseta de text. Dacă facem acest lucru atunci când controlul își pierde focalizarea, se încurcă ordinea filelor
NmaxVal 	Valoarea maximă permisă în control

Metoda SetUp, apelată de metoda Init din TextBox, salvează conținutul proprietății ControlSource în proprietatea personalizată cControlSource înainte de a dezlega controlul de ControlSource. De asemenea, determină și setează InputMask pentru control. Chiar dacă acest cod este executat o singură dată când caseta de text este instanțiată, l-am introdus într-o metodă personalizată pentru a evita codificarea explicit în evenimente ori de câte ori este posibil. Observați că folosim SET('POINT' ) și SET('SEPARATOR' ) pentru a specifica caracterele folosite ca punct zecimal și separator în loc să codificăm un anumit caracter. Acest lucru permite ca controlul să fie utilizat la fel de ușor în Europa ca și în Statele Unite, fără a fi necesară modificarea codului:

LOCAL laFields[1], InElement, InRow, IcIntegerPart, lcDecimalPart, IcMsg

Cu asta

*** Salvați punctul zecimal și caracterele separatoare pentru a putea folosi acest lucru

Clasa *** fie în SUA, fie în Europa

.cPoint = SET('POINT' )

.cSeparator = SET( 'SEPARATOR' )

*** Salvați control Source

DACĂ EMPTY( .cControlSource )

.cControlSource

.ControlSource

ENDIF

Apoi, analizăm numele tabelului și numele câmpului din controlSource. Poate părea redundant să stocați aceste două proprietăți, deoarece ele pot fi obținute cu ușurință prin executarea acestei secțiuni de cod. Cu toate acestea, deoarece există diverse secțiuni de cod care se referă la una sau la alta, este mult mai rapid să le salvați ca proprietăți localizate atunci când caseta de text este instanțiată. S-ar putea să vă întrebați atunci de ce ne-am deranjat să avem o proprietate cControlSource când am fi putut la fel de ușor să facem referire la This.cTable + '.' + This.cField. Credem că acest lucru este mai auto-documentat și face codul mai lizibil. Acest lucru este la fel de important ca și considerentele de performanță. Fiți amabil cu dezvoltatorul care vă moștenește munca. Nu știi niciodată când vei ajunge să lucrezi pentru ea! Acest cod din metoda de configurare a casetei de text își explică scopul foarte clar:

DACĂ ! EMPTY( .cControlSource )

*** Dacă Acesta este un control legat, salvați tabelul și câmpul legat de

*** Analizați numele tabelului dacă ControlSource este prefixat de un alias

DACĂ AT ( '.', .cControlSource ) > 0

.cTable = LEFT( .cControlSource, AT( '.', .cControlSource ) - 1 )

.cField = SUBSTR( .cControlSource, AT( '.', .cControlSource ) + 1 )

ALTE

.cField = .cControlSource

*** Fără alias în ControlSource

*** presupunem că tabelul este cel din zona de lucru selectată în prezent

.ctable = ALIAS()

ENDIF

Rutina de configurare salvează, de asemenea, orice InputMask specificat în proprietatea cInputMask. Dacă acesta este un control legat, nu trebuie să specificați un InputMask, deși puteți face acest lucru dacă doriți. Această secțiune a codului o va face pentru dvs. obținând structura câmpului de bază. De asemenea, setează proprietatea nMaxVal a controlului, necesară în timpul introducerii datelor pentru a se asigura că utilizatorul nu poate introduce un număr prea mare, provocând o eroare de depășire numerică:

*** Aflați cum ar trebui formatat câmpul dacă nu este specificată InputMask

IF EMPTY(.InputMask)

AFIELDS(laFields, .cTable)

lnElement = ASCAN(laFields, UPPER(.cField))

DACA lnElement > 0

*** Dacă câmpul este de tip întreg sau monedă

*** și nu este specificată InputMask, setați-o pentru

*** cea mai mare valoare pe care o va găzdui câmpul

FACE CAZ

CASE laFields[ lnRow, 2 ] = 'I'

.cInputMask = "9999999999"

.nMaxVal = 2147483647

CASE laFields[ lnRow, 2 ] = 'Y'

.cInputMask = "99999999999999.9999"

.nMaxVal = 922337203685477,5807

CASE laFields[ lnRow, 2 ] = 'N'

lcIntegerPart = REPLICATE('9', laFields[lnRow, 3] - ;

laFields[lnRow, 4] - 1)

lcDecimalPart = REPLICATE('9', laFields[lnRow, 4])

.cInputMask = lcIntegerPart + 	+ lcDecimalPart

.nMaxVal = VAL( .cInputMask )

IN CAZ CONTRAR

lcMsg = IIF( INLIST( laFields[ lnRow, 2 ], 'B', 'F' ), ;

„Trebuie să specificați o mască de intrare pentru tipurile de date duble și float”, ;

„Tip de date nevalid pentru acest control” ) + „: „ + This.Name

MESAGEBOX( lcMsg, 16, „Eroare dezvoltator!” )

RETURNARE .F.

ENDCASE

ENDIF

ALTE

.cInputMask = STRTRAN( .InputMask, ',', '' )

.nMaxVal = VAL( .cInputMask )

ENDIF

ALTE

.cInputMask = STRTRAN( .InputMask, ',', '' )

.nMaxVal = VAL( .cInputMask )

ENDIF

Acum că am salvat sursa de control pe proprietatea noastră interna cControlSource, putem dezlega controlul în siguranță. De asemenea, am setat indicatorul IChangingFocus la true. Acest lucru asigură că caseta de text numerică va păstra focalizarea dacă este primul obiect din ordinea tabulatorului când SET('CONFIRM' ) = 'OFF'. Acest lucru este esențial deoarece caseta noastră de text poziționează cursorul utilizând o TASTATĂ „{END}”. Acest lucru ar seta imediat focalizarea pe cel de-al doilea obiect din ordinea de file atunci când formularul este instanțiat, deoarece nu putem forța o SETARE CONFIRM OFF până când caseta noastră de text are de fapt focalizarea:

.ControlSource = ''

*** Acest lucru ne împiedică să introducem tastatura „{END}” și să trecem la următorul control

*** dacă acesta este primul din ordinea de file

.lChangingFocus = .T.

.FormatValue()

SE TERMINA CU

Metoda FormatValue îndeplinește aceeași funcție pe care o face metoda nativă de reîmprospătare Visual FoxPro pentru controalele legate. Acesta actualizează valoarea controlului din ControlSource. De fapt, în acest caz, actualizează valoarea controlului din cControlSource. Deoarece cControlSource evaluează la o valoare numerică, primul lucru pe care trebuie să-l facem este să convertim această valoare într-un șir. Apoi formatăm frumos șirul cu separatoare și poziționăm cursorul la sfârșitul șirului:

Cu asta

*** cControlSource este numeric, deci convertiți-l în șir

DACĂ ! EMPTY ( .cControlSource )

DACĂ ! EMPTY ( EVAL( .cControlSource ) )

.Valoare = ALLTRIM( PADL ( EVAL( .cControlSource ), 32 ) )

ALTE

.Valoare

ENDIF

*** Și formatați-l frumos cu separatore

.AddSeparators()

ALTE

.Valoare = ' '

.InputMask =

ENDIF

*** Poziționați cursorul la capătul din dreapta al casetei de text

DACĂ .IChangingFocus

.IChangingFocus = .F.

ALTE

TASTATURA „{END}”

ENDIF

SE TERMINA CU

Metoda AddSeparators este utilizată pentru a afișa valoarea formatată a casetei de text. Primul pas este de a calcula lungimea porțiunilor întregi și zecimale ale șirului curent:

LOCAL lcInputMask, lnPointPos, lnIntLen, lnDecLen, lnCnt

*** Resetați InputMask cu separatori pentru valoarea curentă a casetei de text

IcInputMask = ''

Cu asta

*** Găsiți lungimea porțiunii întregi a numărului

lnPointPos = AT( .cPoint, ALLTRIM( .Value ) )

DACA lnPointPos = 0

lnIntLen = LEN( .Valoare )

ALTE

lnIntLen = LEN( LEFT(.Value, lnPointPos - 1) )

ENDIF

*** Găsiți lungimea porțiunii zecimale a numărului

DACĂ AT( .cPoint, .cInputMask ) > 0

lnDecLen = LEN( SUBSTR( .cInputMask, AT( .cPoint, .cInputMask ) + 1 ) )

ALTE

lnDecLen = 0

ENDIF

Odată ce am calculat aceste lungimi, putem reconstrui inputMask, inserând virgule acolo unde este cazul. Modul simplu este să numărați caracterele care încep cu caracterul din dreapta al porțiunii întregi a șirului. Putem introduce apoi o virgulă după caracterul format dacă caracterul curent se află în poziția miilor (lnCnt = 4), în poziția milioanelor (lnCnt = 7) și așa mai departe. Cu toate acestea, dacă caseta de text conține o valoare negativă, aceasta ar putea avea ca rezultat afișarea „-,123,456” ca valoare formatată. Verificăm această posibilitate după ce sunt introduse virgulele:

*** Introduceți separatorul la intervalul corespunzător

lcInputMask = ''

PENTRU lnCnt = lnIntLen LA 1 PAS -1

IF INLIST( lnCnt, 4, 7, 10, 13, 16, 19, 21, 24 )

lcInputMask = lcInputMask + 	+ .cSeparator

ALTE

lcInputMask = lcInputMask + „#”

ENDIF

ENDFOR

*** Asigurați-vă că numerele negative sunt formatate corect

IF LEFT( ALLTRIM( .Value ), 1 ) = '-'

DACĂ LEN(lcInputMask) > 3

IF LEFT(lcInputMask, 2 ) = '#,'

IcInputMask = '#' + SUBSTR( lcInputMask, 3 )

ENDIF

ENDIF

ENDIF

Terminăm prin adăugarea unui substituent pentru punctul zecimal și orice substituenți necesari pentru a reprezenta porțiunea zecimală a numărului:

DACA lnPointPos > 0

*** Permiteți punctul zecimal în masca de intrare

lcInputMask = lcInputMask +

*** Adăugați la masca de intrare dacă există o porțiune zecimală

DACĂ lnDecLen > 0

lcInputMask = lcInputMask + REPLICATE( lnDecLen )

ENDIF

ENDIF

.InputMask = lcInputMask

SE TERMINA CU

Pentru ca utilizatorul să introducă date, controlul trebuie să primească focalizare. Acest lucru necesită ca o serie de lucruri să fie făcute în metoda GotFocus. Primul este să ne asigurăm că SET ( 'CONFIRM' ) = 'ON' și că clopoțelul este oprit, altfel vom avea probleme când vom tasta · <end} · să poziționăm cursorul la sfârșitul câmpului. Apoi, trebuie să scoatem separatorii din InputMask și, în cele din urmă, dorim să executăm comportamentul implicit SelectOnEntry al casetei noastre de text din clasa de bază. Deci, codul „Select on Entry” moștenit din metoda GotFocus trebuie modificat pentru a gestiona aceste cerințe suplimentare, după cum urmează:

This.cOldConfirm = SET('CONFIRM')

This.cOldBell = SET('BELL' )

ACTIVATĂ CONFIRMĂ

OPRIȚI SLOPERUL

This.SetInputMask()

DODEFAULT()

Rețineți că metoda SetInputMask este apelată și din metoda HandleKey pentru a ajusta InputMask pe măsură ce utilizatorul introduce date. Iată-l:

LOCAL lcInputMask, lnChar

*** Resetați InputMask pentru valoarea curentă a casetei de text

lcInputMask = ''

FOR InChar = 1 la LEN( This.Value )

lcInputMask = lcInputMask +

ENDFOR

lcInputMask = lcInputMask +

This.InputMask = lcInputMask

La fel ca caseta noastră de text de căutare incrementală, caseta de text numerică gestionează apăsarea tastei în metoda HandleKey care este apelată din InteractiveChange după ce KeyPress a procesat apăsarea tastei. Caseta de text de căutare incrementală nu necesită niciun cod în metoda KeyPress, deoarece toate caracterele sunt potențial valide. În caseta de text numerică, totuși, doar un subset de taste sunt valide. Trebuie să blocăm orice apăsare ilegală a tastelor în metoda KeyPress a controlului și, atunci când este detectată una, emitem un NODEFAULT pentru a suprima intrarea. Facem acest lucru prin trecerea tastei curente la metoda OK2Continue. Dacă este un caracter nevalid, această metodă returnează false la metoda KeyPress, care emite comanda NODEFAULT necesară:

LPARAMETERS tnKeyCode

LOCAL lcCheckVal, llretVal

llRetVal = .T.

Cu asta

Deoarece caracterul curent nu devine o parte a valorii casetei de text decât după finalizarea metodei InteractiveChange, putem preveni mai multe puncte zecimale verificându-le aici:

FACE CAZ

*** Asigurați-vă că permitem doar o zecimală în intrare

CASE CHR( tnKeyCode ) = .cPoint && punct zecimal

DACĂ AT ( .cPoint, .Value ) > 0

llRetVal = .F.

ENDIF

De asemenea, nu vom permite introducerea unui semn minus decât dacă este primul caracter din șir:

*** Asigurați-vă că avem doar un semn minus la începutul numărului

CASE tnKeyCode = 45

DACĂ .SelStart > 0

llRetVal = .F.

ENDIF

Cea mai complexă sarcină gestionată de metoda OK2Continue este verificarea depășirii numerice. Facem acest lucru determinând care va fi valoarea dacă permitem apăsarea curentă a tastei și comparăm această valoare cu cea stocată în proprietatea nMaxVal a controlului:

*** Apărați-vă împotriva depășirii numerice!!!!

IN CAZ CONTRAR

DACĂ ! GOL ( .cInputMask )

DACĂ .SelLength = 0

DACĂ tnKeyCode > 47 ȘI tnKeyCode < 58

FACE CAZ

CAZ .SelStart = 0

lcCheckVal = CHR( tnKeyCode ) + ALLTRIM( .Value )

CAZ .SelStart = LEN( ALLTRIM( .Valoare ) )

lcCheckVal = ALLTRIM( .Value ) + CHR( tnKeyCode )

IN CAZ CONTRAR

lcCheckVal = LEFT( .Value, .SelStart ) + CHR( tnKeyCode ) + ;

ALLTRIM( SUBSTR( .Valoare, .SelStart + 1 ) )

ENDCASE

IF ABS( VAL( lcCheckVal ) ) > .nMaxVal

llRetVal = .F.

ENDIF

*** Asigurați-vă că, dacă masca de intrare specifică a

*** un anumit număr de zecimale, nu permitem mai multe

*** decât numărul de zecimale specificat

DACĂ AT ( '.', lcCheckVal ) > 0

DACĂ AT( '.', .cInputMask ) > 0

DACĂ LEN( JUSTEXT( lcCheckVal ) ) > LEN( JUSTEXT( .cInputMask ) )

llretVal = .F.

ENDIF

ENDIF

ENDIF

ENDIF && tnKeyCode > 47 ȘI tnKeyCode < 58

ENDIF && .SelLength = 0

ENDIF && ! GOL ( .cInputMask )

ENDCASE

SE TERMINA CU

RETURN llRetVal

Acest cod poate arăta destul de urât, dar de fapt se execută extrem de rapid, deoarece structura IF imbricată asigură că diferite verificări sunt efectuate secvenţial și că, dacă vreuna nu reușește, restul nu sunt niciodată procesate.

La fel ca caseta noastră de text de căutare incrementală, se lucrează mult folosind puțin cod în metoda noastră HandleKey. Ne putem ocupa de poziționarea cursorului și formatarea valorii aici, deoarece InteractiveChange se va declanșa numai după ce KeyPress a reușit. Prin urmare, gestionarea apăsărilor de taste aici necesită mai puțin cod decât manipularea lor direct în KeyPress:

LOCAL lcInputMask, lnSelStart, lnEnd

*** Salvați punctul de inserare al cursorului și lungimea valorii introduse până acum

lnSelStart = This.SelStart

lnEnd = LEN(Această.Valoare) - 1

Cu asta

*** Scăpați de orice spații de sfârșit, astfel încât să putem justifica corect valoarea

.Valoare = ALLTRIM(.Valoare)

*** Avem nevoie de o manipulare specială pentru a elimina punctul zecimal

DACĂ LASTKEY() = 127 && backspace

DACA .Valoare = .cPoint

.Valoare

.InputMask =

ENDIF

ENDIF

.SetInputMask()

Dacă caracterul tocmai introdus se afla în mijlocul casetei de text, lăsăm cursorul acolo unde se afla. În caz contrar, îl poziționăm în mod explicit la sfârșitul valorii introduse în prezent:

IF InSelStart >= InEnd

TASTATURA „{END}”

ALTE

.SelStart = lnSelStart

ENDIF

SE TERMINA CU

Aproape acum! Dacă acesta a fost inițial un control legat, trebuie să actualizăm câmpul specificat de proprietatea cControlSource. Metoda Valid este locul potrivit pentru aceasta, așa că o folosim:

Cu asta

DACĂ ! EMPTY( .cControlSource )

ÎNLOCUITĂ ( .cField ) CU VAL( .Value ) ÎN ( .cTable )

ENDIF

SE TERMINA CU

În cele din urmă, avem nevoie de puțin cod în metoda LostFocus a casetei de text pentru a reseta confirmarea la valoarea inițială și pentru a formata valoarea afișată cu separatorii corespunzători:

Cu asta

*** Setați steag, astfel încât să nu dăm un capăt de la tastatură și să nu greșim ordinea filelor

.lChangingFocus = .T.

.Reîmprospăta()

IF .cOldConfirm = 'OFF'

SETARE CONFIRMARE OFF

ENDIF

SE TERMINA CU
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Timp de manipulare

Una dintre problemele perene la construirea unei interfețe cu utilizatorul este modul de a gestiona intrarea timpului. Multe aplicații necesită acest suport și am văzut abordări variate, adesea bazate pe comenzile spinner. Considerăm că există de fapt două tipuri de introducere a timpului care trebuie luate în considerare, iar diferențele lor necesită controale diferite.

Mai întâi este introducerea directă a unui timp real. De obicei, aceasta va fi folosită într-o situație de înregistrare a timpului, când utilizatorul trebuie să introducă, de exemplu, o oră de început și o oră de sfârșit pentru o sarcină. Acesta este un scenariu pur de introducere a datelor și o casetă de text este cel mai bun instrument pentru job, dar există unele probleme care trebuie abordate.

În al doilea rând, este introducerea timpului ca interval sau setare. De obicei, acest tip va fi utilizat într-o situație de planificare când utilizatorul trebuie să introducă, de exemplu, durata estimată pentru o sarcină. În acest caz, un spinner este foarte potrivit pentru sarcină, deoarece utilizatorii pot ajusta cu ușurință valoarea în sus sau în jos și pot vedea impactul modificărilor lor.

O casetă de text pentru introducerea orei (Exemplu: CH04.VCX::txtTime)

Presupunerea de bază aici este că o valoare de timp va fi întotdeauna stocată ca șir de caractere în forma hh:mm. Nu ne așteptăm să gestionăm secunde în acest tip de situație de intrare directă. De fapt, acest lucru nu este nerezonabil, deoarece majoritatea manipulării timpului necesită doar o precizie de ore și minute. Acest lucru este cel mai ușor atunci când valoarea este deja sub formă de caracter. (Dacă într-adevăr trebuie să introduceți secunde, ar fi o problemă simplă să transformați acest control într-o subclasă pentru a le gestiona.) De asemenea, am decis să lucrăm la un ceas de 24 de ore. Din nou, acest lucru simplifică interfața prin eliminarea necesității de a adăuga conceptul familiar de desemnare AM/PM.

Aceste decizii fac interfața cu utilizatorul clasei simplu de construit, deoarece Visual FoxPro ne oferă atât o proprietate InputMask, cât și o proprietate Format. Primul specifică modul în care datele introduse în control trebuie interpretate, în timp ce al doilea definește modul în care ar trebui să fie afișate. În clasa noastră txtTime (pe baza clasei noastre txtbase), aceste proprietăți sunt definite după cum urmează:

InputMask = 99:99

Format = R

„R” din format îi spune Visual FoxPro să folosească masca de intrare definită, dar să nu includă caracterele de formatare ca parte a valorii care urmează să fie stocată. Deși poate fi folosit doar cu date cu caractere și cifre, este într-adevăr foarte util. În acest caz, separatorul „:” este întotdeauna vizibil, dar nu este de fapt stocat împreună cu valoarea. Prin urmare, este întotdeauna un șir de patru caractere.

Avem un cod suplimentar în ambele metode GotFocus și LostFocus pentru a salva și a restabili setarea curentă de confirmare și pentru a o forța să se activeze în timp ce caseta de text de introducere a timpului este focalizată. Deși nu este absolut necesar, considerăm că este o practică bună atunci când limitați lungimile de intrare pentru a ne asigura că confirmarea este activată pentru a preveni utilizatorii să tasteze din greșeală în câmp.

Tot codul rămas din clasă se află în metoda Valid a casetei de text și aici trebuie să abordăm problemele menționate mai sus despre modul în care utilizatorii vor folosi acest control. Problema cheie este cum să gestionați timpii parțiali. De exemplu, dacă un utilizator introduce șirul: „011· înseamnă de fapt „01:10” (zece minute după unu dimineața) sau „00:11” (unsprezece minute după miezul nopții)? Ce zici de o intrare de „09”?

De fapt, nu există un mod absolut de a cunoaște. Tot ce putem face este să definim și să implementăm câteva reguli rezonabile pentru această clasă, după cum urmează:

Tabelul 4.3 Reguli pentru introducerea unei valori de timp

Utilizatorul introduce 	Interpret asResult
1 	O anumită oră, fără minute01:00
11 	ore, fără minute11:00
111 	ore și minute, zero în frunte omis01:11
1111 	Ora exactă11:11

Codul care implementează aceste reguli este destul de simplu:

LOCAL luHrs, luMins, lcTime, lnLen

*** Notă: trebuie să presupunem că un utilizator omite doar începutul sau finalul

*** zerouri. Altfel nu putem ghici rezultatul dorit!!!

lcTime = ALLTRIM(This.Value)

lnLen = LEN(lcTime)

FACE CAZ

CAZ lnLen = 4

*** Avem 4 cifre deci avem un timp complet!

*** Nu face nimic altceva

CAZ lnLen = 3

*** Să presupunem că minutele sunt corecte, orele înainte de zero au fost omise

lcTime = PADL( lcTime, 4, ·0· )

CAZ lnLen = 2

*** Să presupunem că doar avem ore, nu minute

lcTime = PADR( lcTime, 4, ·0· )

IN CAZ CONTRAR

*** Un singur număr trebuie să fie o oră!

IcTime = "0" + lcTime + "00"

ENDCASE

*** Obțineți componentele Ore și minute

luHrs = LEFT( lcTime, 2 )

luMins = RIGHT( lcTime, 2 )

*** Verificați dacă nu am depășit ora 23:59 sau mai puțin de 00:00

DACĂ ! BETWEEN( INT(VAL(luMins)), 0, 59) SAU ! BETWEEN( INT(VAL(luHrs)), 0, 23)

Așteptați „Ora introdusă nevalidă” FEREASTRA ACUM Așteptați

This.Value = ""

RETURNARE 0

ALTE

Aceasta.Valoare = luHrs + luMins

RETURNARE 1

ENDIF

O clasă compusă cu introducere de timp (Exemplu: CH04.VC^::CntTime)

După cum sa menționat în introducerea acestei secțiuni, un control rotativ este util atunci când trebuie să oferiți utilizatorului posibilitatea de a schimba orele, spre deosebire de introducerea lor directă. Cu toate acestea, o diferență semnificativă între folosirea unui spinner și a unei casete de text pentru a introduce timpul este că un spinner necesită o valoare numerică. Aceasta înseamnă că, dacă vrem totuși să stocăm valoarea noastră de timp ca șir de caractere, trebuie să facem conversia din caracter în numeric și înapoi. Pentru simplitate, acest control este configurat să afișeze întotdeauna o oră în format hh:mm:ss și se așteaptă ca, dacă este legat, acesta să fie legat la un câmp Caracter (6). (Scopul aici este de a arăta tehnicile de bază. Modificarea controlului pentru alte scenarii este lăsată ca un exercițiu pentru cititor.)

Următoarea problemă este cum să obțineți timpul să fie semnificativ ca valoare numerică pentru a se afișa corect. Din fericire, putem folosi din nou proprietățile Format și InputMask pentru a rezolva această dilemă. Prin setarea Spinner's InputMask = 99:99:99 și Format = "RL", putem afișa o valoare numerică de șase cifre cu zerouri de început. (Opțiunea „L” funcționează numai cu valori numerice, așa că nu am putea-o folosi în exemplul precedent.)

Ultima problemă pe care trebuie să o rezolvăm este modul de a determina care parte din numărul nostru de șase cifre va fi schimbată atunci când se face clic pe butoanele sus/jos ale rotorului. Soluția este de a crea o clasă compozită care se bazează pe un container cu un spinner și un grup de opțiuni cu trei butoane. Grupul de opțiuni este folosit pentru a determina care parte a rotorului este incrementată (adică ore, minute sau secunde), iar metodele UpClick și DownClick ale Spinner sunt codificate pentru a acționa corespunzător. Iată clasa în uz:

Figura 4.2 Time Spinner Control

Containerul filatorului de timp

Containerul este o subclasă a clasei noastre standard cntBase, cu o singură proprietate personalizată (cControlSource) și o metodă personalizată (SetSpinValue). Acestea se ocupă de cerința de a converti între o sursă de date de caractere pentru clasa noastră și valoarea numerică cerută de spinner. Proprietatea cControlSource este populată în momentul proiectării cu numele sursei de control pentru spinner. Codul a fost adăugat la metoda Refresh a containerului pentru a apela metoda SetSpinValue pentru a efectua conversia atunci când controlul este legat. Codul de reîmprospătare este pur și simplu:

Cu asta

IF !EMPTY( .cControlSource )

This.SetSpinValue()

ENDIF

SE TERMINA CU

Codul din SetSpinValue este la fel de simplu, doar convertește valoarea sursei de control într-un număr de șase cifre completat cu zerouri. Cu toate acestea, există o problemă aici - observați utilizarea funcției INT() în această conversie. Trebuie să ne asigurăm că valoarea noastră numerică este de fapt un număr întreg în orice moment. Indiferent dacă avem de-a face cu ore, minute sau secunde se bazează pe pozițiile cifrelor în valoarea numerică și zecimale ar interfera atunci când se utilizează funcțiile PADx():

Cu asta

IF !EMPTY( .cControlSource )

.spnTime.Value = INT( VAL( PADL( EVAL( .cControlSource ), 6, "0" )))

ENDIF

SE TERMINA CU

Grupul de opțiuni pentru time spinner

Aceasta este cea mai simplă parte a clasei. Nu are niciun cod personalizat, în afară de schimbarea numelui său de la Visual FoxPro implicit la OptPick. Comportamentul nativ al unui grup de opțiuni este de a înregistra, în proprietatea Value a grupului propriu-zis, numărul butonului de opțiune selectat. Deoarece trebuie doar să știm ce buton este selectat, nu trebuie să facem nimic altceva.

Învârtitorul de timp

Acesta este, fără a fi surprinzător, locul în care se face cea mai mare parte a muncii din clasă. Au fost setate trei proprietăți - InputMask și Format (pentru a gestiona problemele de afișare) și Increment. Acesta a fost setat la 0 pentru a suprima comportamentul nativ al filatorului, deoarece trebuie să gestionăm schimbarea valorii într-un mod mai sofisticat.

Metodele GotFocus și LostFocus sunt folosite pentru a opri și reporni cursorul, deoarece acest control nu este destinat tastării directe, eliminând necesitatea de a afișa cursorul.

Metoda Valid gestionează conversia valorii numerice a filatorului înapoi într-un șir de caractere și, dacă controlul este legat, se ocupă de înlocuire pentru a actualiza sursa de control. Acest cod este, de asemenea, destul de simplu:

CU Aceasta.Părinte

IF !EMPTY( .cControlSource )

ÎNLOCUIȚI (.cControlSource) CU PADL( INT( This.Value ), 6, "0" )

ENDIF

SE TERMINA CU

Biții complicati sunt gestionați în metodele UpClick și DownClick. Deși acest cod poate părea puțin descurajant la prima vedere, este într-adevăr destul de simplu și se bazează pe interpretarea poziției cifrelor în valoarea numerică și gestionarea lor în consecință. Metoda UpClick verifică setarea grupului de opțiuni și incrementează porțiunea relevantă a valorii numerice:

LOCAL lnPick, lnNewVal, lnHrs, lnMins, lnSecs

lnPick = This.Parent.optPick.Value

FACE CAZ

CAZ lnPick = 1 && ore

*** Obțineți valoarea următoarelor ore

lnNewVal = This.Value + 10000

*** Dacă 24 sau mai mult, resetați la 0 prin scădere

This.Value = IIF( lnNewVal >= 240000, lnNewVal - 240000, lnNewVal )

CAZ lnPick = 2 && Min

*** Obțineți următoarea valoare ca șir de caractere

lcNewVal = PADL(INT(This.Value) + 100, 6, '0' )

*** Extrageți orele ca valoare înmulțită cu 10000

lnHrs = VAL(STÂNGA(lcNewVal,2)) * 10000

*** Obțineți minutele ca șir de caractere

lnMins = SUBSTR( lcNewVal, 3, 2)

*** Verificați valoarea acestui șir și fie înmulțiți cu 100

*** sau, dacă este peste 59, rulați-l la 00

lnMins = VAL(IIF( VAL(lnMins) > 59, „00”, lnMins )) * 100

*** Extrageți porțiunea de secunde

lnSecs = VAL(DREPTA(lcNewVal, 2 ))

*** Reconstituiți valoarea numerică

Aceasta.Valoare = lnHrs + lnMins + lnSecs

CAZ lnPick = 3 && sec

*** Obțineți următoarea valoare ca șir de caractere

lcNewVal = PADL(INT(This.Value) + 1, 6, '0' )

*** Extrageți orele ca valoare înmulțită cu 10000

lnHrs = VAL(STÂNGA(lcNewVal,2)) * 10000

*** Extrageți minutele ca valoare înmulțită cu 100

lnMins = VAL(SUBSTR( lcNewVal, 3, 2)) * 100

*** Obțineți secundele ca șir de caractere

lnSecs = RIGHT( lcNewVal, 2)

*** Verificați valoarea acestui șir,

*** Dacă este peste 59, treceți-l la 00

lnSecs = VAL(IIF( VAL(lnSecs) > 59, „00”, lnSecs ))

*** Reconstituiți valoarea numerică

Aceasta.Valoare = lnHrs + lnMins + lnSecs

ENDCASE

Pentru ore, incrementul este 10000, pentru minute este 100 și pentru secunde este doar 1.

Controlul este conceput astfel încât, dacă utilizatorul încearcă să crească porțiunea de ore peste „23”, acesta trece la „00”, pur și simplu scăzând valoarea 240000 din noua valoare a rotorului. Atât minutele, cât și secundele sunt transferate de la „59” la „00”, dar în acest caz trebuie să excludem fiecare componentă a timpului pentru a verifica porțiunea relevantă înainte de a reconstrui valoarea prin adunarea părților individuale.

O abordare similară a fost luată în metoda DownClick, care scade valoarea controlului. În acest caz, trebuie să stocăm valoarea curentă și să o folosim pentru a menține setările părților controlului care nu sunt afectate. În caz contrar, principiile sunt aceleași ca și pentru metoda UpClick:

LOCAL lnPick, lcNewVal, lnHrs, lnMins, lnSecs, lcOldVal

*** Obțineți valoarea curentă a controlului ca șir

lcOldVal = PADL(INT(This.Value), 6, '0' )

lnPick = This.Parent.optPick.Value

FACE CAZ

CAZ lnPick = 1 && ore

*** Reduceți porțiunea de ore

lnHrs = VAL( LEFT( lcOldVal, 2 ) ) - 1

*** Dacă se află în intervalul dorit, utilizați-l, altfel setați la 0

lnHrs = IIF( BETWEEN(lnHrs, 0, 23), lnHrs, 23 ) * 10000

*** Extrage procesul verbal

lnMins = VAL(SUBSTR( lcOldVal, 3, 2)) * 100

*** Extrageți secundele

lnSecs = VAL(DREPTA(lcOldVal, 2))

CAZ lnPick = 2 && Min

*** Determinați valoarea nouă, decrementată

lcNewVal = PADL(INT(This.Value) - 100, 6, '0' )

*** Preluați porțiunea de ore curentă

lnHrs = VAL(STÂNGA(lcOldVal,2)) * 10000

*** Obțineți porțiunea de minute din noua valoare

lnMins = VAL(SUBSTR( lcNewVal, 3, 2))

*** Verificați valabilitatea intervalului, setat la 0 dacă nu este valid

lnMins = IIF( BETWEEN( lnMins, 0, 59), lnMins, 59 ) * 100

*** Preluați porțiunea curentă de secunde

lnSecs = VAL(DREPTA(lcOldVal, 2 ))

CAZ lnPick = 3 && sec

*** Determinați valoarea nouă, decrementată

lcNewVal = PADL(INT(This.Value) - 1, 6, '0' )

*** Preluați porțiunea de ore curentă

lnHrs = VAL(STÂNGA(lcOldVal,2)) * 10000

*** Preluați porțiunea curentă de minute

lnMins = VAL(SUBSTR( lcOldVal, 3, 2)) * 100

*** Obțineți porțiunea Secunde din noua valoare

lnSecs = VAL(DREPTA(lcNewVal, 2))

*** Verificați valabilitatea intervalului, setat la 0 dacă nu este valid

lnSecs = IIF( BETWEEN(lnSecs, 0, 59), lnSecs, 59 )

ENDCASE

*** Setați Valoarea la rezultatul nou, decrementat

Aceasta.Valoare

InHrs + InMins + InSecs

Concluzie

Acest turnător de timp este oarecum limitat în capacitatea sa de a gestiona mai mult decât mediul simplu pe care l-am definit pentru el. Deși este clar pentru utilizatorul final, mecanismul de selectare a părții de timp care trebuie crescută sau decrementată este puțin greoi. O soluție mai elegantă este oferită în controlul final din această secțiune.

Spinerul de timp real (Exemplu: CH04.VCX::spnTime)

Acest control arată și acționează la fel ca un indicator de timp pe care îl vedeți când utilizați controlul ActiveX Data/Time Picker livrat cu Visual Studio. Cu toate acestea, are câteva caracteristici care îl fac mai util în general decât controlul ActiveX. În primul rând, acest control nu necesită ca acesta să fie legat la un câmp de tipul de date DateTime. După cum am spus, cel mai bun format pentru stocarea timpului introdus de utilizator este într-un câmp de caractere formatat pentru a include separatorul universal de timp. Controlul poate fi configurat să afișeze și să recunoască fie un format de 5 caractere „hh:mm”, fie un format complet de 8 caractere „hh:mm:ss” și să fie actualizat în mod corespunzător. Aceasta este controlată de o singură proprietate, lShowSeconds. În cele din urmă, deoarece acesta este un control Visual FoxPro nativ, nu suferă de problemele inerente care bântuie controalele ActiveX cu privire la versiunile multiple ale DLL-urilor specifice Windows și nici nu există probleme asociate cu înregistrarea controlului.

Ca și în cazul spinner-ului bazat pe container, acest control utilizează o proprietate cControlSource pentru legarea la o sursă de date externă și are metode asociate (RefreshSpinner și UpdateControlSource) pentru a gestiona problema conversiei între valorile caracter (sursă) și numerice (interne) și înapoi. Spre deosebire de spinner-ul bazat pe container, acest control poate gestiona, de asemenea, legarea la o proprietate de formular, precum și la o sursă de date. Metoda UpdateControlSource, numită din metoda Valid a filatorului, permite spinner-ului de timp, care este într-adevăr un control nelegat, să se comporte exact ca unul care este legat atunci când proprietatea sa cControlSource este setată:

LOCAL lcTable, lcField, IcValue, IcTemp

Cu asta

*** Analizați numele tabelului și al câmpului în cControlSource

DACĂ ! EMPTY( .cControlSource )

*** Obțineți numele tabelului dacă ControlSource este prefațată de un alias

DACĂ '.' $ .cControlSource

lcTable = LEFT( .cControlSource, AT( '.', .cControlSource ) - 1 )

lcField = SUBSTR( .cControlSource, AT( '.', .cControlSource ) + 1 )

ALTE

*** Să presupunem că aliasul este aliasul selectat curent dacă nu este specificat niciunul.

*** Acest lucru este puțin periculos, dar dacă este o presupunere proastă, atunci

*** programul va exploda foarte repede în modul de dezvoltare oferind

*** dezvoltatorului o indicație foarte clară a ceea ce este în neregulă odată ce verifică

*** rezolvați problema în depanator.

lcTable = ALIAS()

lcField

.cControlSource

ENDIF

Acum trebuie să convertim valoarea numerică a spinnerului în valoarea caracterului cerută de proprietatea câmpului sau a formularului specificată în cControlSource dacă acesta este un control legat. De asemenea, trebuie să formatăm acest șir de caractere cu două puncte și să luăm în considerare dacă folosim formatul hh:mm sau hh:mm:ss:

IcTemp = IIF( .IShowSeconds, PADL( INT ( .Value ), 6, '0' ), ; PADL( INT ( .Value ), 4, '0' ) )

lcValue = LEFT( lcTemp, 2 ) + ':' + SUBSTR( lcTemp, 3, 2 ) + ; IIF( .lShowSeconds, ':' + RIGHT( lcTemp, 2 ), '' )

*** Verificați aici pentru a vedea dacă aliasul nostru este ThisForm. Dacă este,

*** vom presupune că suntem legați la o proprietate de formă IF UPPER( lcTable ) = 'THISFORM'

STORE lcValue TO ( .cControlSource )

ALTE

ÎNLOCUIȚI ( lcField ) CU lcValue IN ( lcTable )

ENDIF

ENDIF

SE TERMINA CU

În schimb, metoda RefreshSpinner actualizează valoarea spinner-ului din cControlSource. În controalele reale legate, această funcție este gestionată automat ori de câte ori controlul este reîmprospătat. Metoda noastră RefreshSpinner este apelată din Refresh-ul spinnerului pentru a oferi această funcționalitate:

Cu asta

DACĂ ! EMPTY( .cControlSource )

.Valoare = IIF(

.lShowSeconds, ;

VAL( STRTRAN(

EVAL( .cControlSource )

'' ) ), ;

VAL( STRTRAN(

LEFT ( EVAL( .cControlSource

), 5 )

'' ) ) )

ALTE

.Valoare = IIF(

.lShowSeconds, VAL( STRTRAN(

TIMP()

'' ) ), ;

VAL( STRTRAN(

LASAT ( TIME ( ) , 5)

'' ) ) )

ENDIF

SE TERMINA CU

Pentru a schimba ora, un utilizator trebuie doar să facă clic pe ora, minutele sau secundele afișate și apoi să crească sau să scadă acea valoare. Alternativ, ora poate fi introdusă tastând direct în control, iar tastele cursor stânga și dreapta pot fi folosite pentru a naviga în cadrul controlului. Orele sunt limitate la intervalul 0 - 23, iar minutele și secundele la intervalul 0 - 59. Fiecare unitate de timp acționează independent și trece de la limita sa superioară la cea inferioară și invers (la fel ca setarea unui ceas cu alarmă digital).

La început ne-am gândit că vom implementa o funcție de derulare continuă cu ajutorul rotativului nostru de timp. Nu a durat mult până când am renunțat la idee. Am descoperit rapid că nu există o modalitate convenabilă de a implementa această funcționalitate din cauza ordinii în care se declanșează evenimentele spinner. După cum v-ați putea aștepta, evenimentul MouseDown are loc mai întâi. Totuși, acesta este urmat de evenimentul MouseUp urmat fie de metoda UpClick, fie de DownClick. Puteți vedea singur acest comportament ținând apăsată săgeata în jos a rotorului. Rotitorul nu își crește sau scade valoarea până când eliberezi mouse-ul!

Logica folosită pentru a incrementa și a decrementa diferitele segmente de timp este similară cu cea discutată anterior. Diferența principală dintre acest control și containerul discutat mai sus este metodologia utilizată pentru a determina ce segment de timp să crească sau să decrementeze. Deoarece făcând clic pe săgeata sus sau pe săgeata în jos a rotorului face ca proprietatea SelStart a controlului să fie resetata la zero, această valoare este salvată în proprietatea personalizată a rotorului nSelStart ori de câte ori este selectat un anumit segment de timp. Controlul folosește două metode personalizate, SetHighlight și MoveHighlight pentru a selecta segmentul de timp corespunzător și pentru a stoca poziția cursorului în această proprietate. Metoda SetHightlight de mai jos este utilizată pentru a selecta segmentul de timp corespunzător ori de câte ori utilizatorul face clic în rotisor cu mouse-ul:

Cu asta

FACE CAZ

*** Ore de evidențiere

CAZUL ÎNTRE( .SelStart, 0, 2 )

.SelStart = 0

*** Evidențiați minutele

CAZ ÎNTRE( .SelStart, 3, 5 )

.SelStart = 3

IN CAZ CONTRAR

*** Evidențiați secundele dacă este cazul

.SelStart = IIF( .lShowSeconds, 6, 0 )

ENDCASE

.SelLength = 2

*** Salvați punctul de inserare

.nSelStart = .SelStart

SE TERMINA CU

Metoda MoveHighlight se ocupă de mutarea evidențierii în segmentul corespunzător al rotitoarei atunci când utilizatorul apasă fie tastele cursor dreapta (codul tastei = 4) fie stânga (codul cheie = 19). Este apelat din metoda KeyPress a spinnerului dacă segmentul de timp curent conține o valoare validă. Când utilizatorul introduce un segment de timp direct în control, metoda ValidateSegment este apelată pentru a se asigura că se află în intervalul corect. Dacă nu este, proprietatea lSegmentIsValid a time spinner este setată la false. Acest lucru împiedică utilizatorul să se deplaseze fie la un segment diferit din cadrul controlului, fie la orice alt obiect din formular fără a corecta mai întâi intrarea:

LOCAL llDecrement

Cu asta

FACE CAZ

CAZ nKeyCode = 19 SAU nKeyCode = 4

DACĂ .lSegmentIsValid

.MoveHighlight( nKeyCode )

ENDIF

NODEFAULT

CAZ nKeyCode = 5 SAU nKeyCode = 24 && Săgeată sus sau jos

DACĂ nKeyCode = 24

llDecrement = .T.

ENDIF

ChangeTime(llDecrement)

SelStart

.nSelStart

SelLength = 2

NODEFAULT

IN CAZ CONTRAR

*** Așa că nu încurcăm ora formatată

*** Dacă începem să tastăm numere și este selectată o parte din valoare,

*** pierdem cifre, iar cele rămase se schimbă

.SelLength = 0

*** Dacă introducem un număr direct în control,

*** asigurați-vă că este o valoare valabilă pentru ore, minute sau secunde

DACĂ ÎNTRE( nKeyCode, 48, 57 )

Spinner::KeyPress( nKeyCode, nShiftAltCtrl)

.ValidateSegment()

DACĂ ! .lSegmentIsValid

.SelStart = .nSelStart

.SelLength = 2

ENDIF

NODEFAULT

ENDIF

ENDCASE

SE TERMINA CU

Metoda MoveHighlight este oarecum similară cu metoda SetHighlight de mai sus. Pe baza locației curente a cursorului și a tastei care tocmai a fost apăsată, acesta decide ce segment de timp să selecteze:

Cu asta

FACE CAZ

CAZUL ÎNTRE( .SelStart, 0, 2 )

DACĂ .lShowSeconds

.SelStart = IIF( nKeyCode = 19, 6, 3 )

ALTE

.SelStart = 3

ENDIF

CAZ ÎNTRE( .SelStart, 3, 5 )

DACĂ .lShowSeconds

.SelStart = IIF( nKeyCode = 19, 0, 6 )

ALTE

.SelStart = 0

ENDIF

IN CAZ CONTRAR

.SelStart = IIF( nKeyCode = 19, 3, 0 )

ENDCASE

.SelLength = 2

.nSelStart = .SelStart ENDWITH

Creșterea și decrementarea segmentelor de timp se ocupă de metoda ChangeTime. Aceasta este o metodă supraîncărcată care este apelată atât de la metodele UpClick, cât și de la DownClick. Un singur parametru logic transmis acestei funcții îi spune dacă să crească sau să decrementeze sau nu

segment specificat. Metoda ChangeTime invocă apoi metoda adecvată pentru a gestiona calculele orelor și minutelor. Deoarece manipularea valorii secunde este atât de simplă, este gestionată direct în metoda ChangeTime:

LPARAMETRI tlDecrementare

*** când tlDecrement este adevărat, scădem timpul, altfel suntem

*** în creștere. În primul rând, trebuie să selectăm de ce segment este ajustat

*** examinând valoarea salvată anterior pentru nselstart

Cu asta

FACE CAZ

CASE BETWEEN( .nSelStart, 0, 2 ) .IncrementHours( tlDecrement ) CASE BETWEEN( .nSelStart, 3, 5 ) .IncrementMinutes( tlDecrement ) ALTRE

IF tlDecrementare

%

.Valoare = IIF(

INT( .Valoare

100

) = 0 SAU INT( .Valoare % 100 > 59 ), ;

INT( .Valoare /

100) * 100

59

.Valoare - 1)

ALTE

.Valoare = IIF(

INT( .Valoare

100

) > 58, ;

+

%

INT( .Valoare /

100 ) * 100, .Valoare + 1 )

ENDIF

ENDCASE

.lSegmentIsValid = .T.

SE TERMINA CU

Copyright 2000 de către Marcia Akins, Andy Kramek și Rick Schummer Toate drepturile rezervate

Etichete intermitente (Exemplu: CH04.VCX::cntLblBlink)

Chiar dacă o parte din această echipă de scriitori este britanică, acesta nu este un comentariu derizoriu despre etichete. În vremurile FoxPro pentru DOS și FoxPro pentru Windows, am putea specifica un text intermitent prin setarea unui cod de format „B”. Din păcate, acest lucru nu mai funcționează în Visual FoxPro. Cu toate acestea, dacă aveți nevoie ocazional de o etichetă intermitentă, crearea acestei clase este foarte simplă.

Tot ce aveți nevoie este un container cu backStyle setat la 0-transparent și borderwidth setat la 0. Aruncați o etichetă și un cronometru în container. Setați intervalul temporizatorului la 300 și adăugați următoarea linie de cod la metoda temporizatorului:

CU This.Parent.lblBase

.Vizibil = !.Vizibil

SE TERMINA CU

Voila! Etichete intermitente!
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Caseta de editare expendïnÇJ (Exemplu: CH04.VCX::edtBase)

Unul dintre dezavantajele casetei de editare a clasei de bază Visual FoxPro este că poate fi prea mică pentru a permite utilizatorului să vadă tot textul din câmpul de memorare afișat. Putem rezolva această problemă destul de ușor adăugând câteva proprietăți casetei noastre de editare a clasei de bază și câteva metode pentru a o micșora și extinde.

La prima vedere, cineva poate fi tentat să extindă automat caseta de editare când se focalizează și să o micșoreze din nou când își pierde focalizarea. Cu toate acestea, reflectând probabil, veți considera că acest lucru nu ar fi un design bun de interfață și ar fi, cel puțin, oarecum deconcertant pentru utilizatorul final. Prin urmare, am optat pentru a permite utilizatorului să extindă și să micșoreze caseta de editare prin crearea unui meniu cu comenzi rapide numite din metoda RightClick din caseta de editare. Acest meniu oferă utilizatorului și posibilitatea de a schimba fontul textului afișat în caseta de editare. (Utilizatorii dvs. finali vor aprecia capacitatea de a ușura privirea asupra străinilor prin mărirea fontului, mai ales atunci când câmpurile de memorii care urmează să fie editate sunt lungi.)

Figura 4.3 Caseta de editare care se extinde la instanțiere

Figura 4.4 Caseta de editare extinsă atunci când este maximizată cu font modificat

Clasa noastră de casetă de editare în extindere utilizează nouă proprietăți personalizate, dintre care numai primele trei necesită orice manipulare directă - dar numai dacă doriți să schimbați comportamentul implicit.

Tabelul 4.4 Proprietăți personalizate ale casetei de editare extinse

Descrierea proprietății	
ICIeanUpOnExit 	Setați la true pentru a elimina caracterele care nu pot fi imprimate de la sfârșitul notei
IPositionAtEnd 	Când este adevărat, poziționează cursorul la sfârșitul textului existent atunci când caseta de editare devine focalizată
IResize 	Când este adevărat, activează opțiunea de a extinde și micșora caseta de editare atunci când utilizatorul face clic dreapta în caseta de editare pentru a afișa meniul de comenzi rapide
IMaximized 	Setați la true când caseta de editare este maximizată și false când nu este
nOrigColWidths	

	Salvează lățimile coloanelor originale ale tuturor coloanelor din grila care conține această casetă de editare, astfel încât să putem extinde caseta de editare pentru a ocupa spațiul întregii părți vizibile a grilei
nOrigHeight 	Înălțimea casetei de editare la instanțiere
nOrigLeft 	Stânga casetei de editare la instanțiere
nOrigRowHeight 	RowHeight originală a grilei care conține caseta de editare (dacă caseta de editare este conținută într-o grilă)
nOrigTop 	Partea de sus a casetei de editare la instanțiere
nOrigWidth 	Lățimea casetei de editare la instanțiere

Apropo, acest control special va funcționa așa cum este, chiar și atunci când este în interiorul unei rețele, în ciuda precauției de la începutul acestui capitol. Deci cum funcționează? Când controlul este instanțiat, un apel de la metoda sa Init rulează metoda personalizată SaveOriginalDimensions, care face exact ceea ce implică numele său:

LOCAL InCol

Cu asta

*** Salvați dimensiunile și poziția originale ale casetei de editare

.nOrigHeight = .Înălțime

.nOrigWidth = .Latime

.nOrigTop = .Sus

.nOrigLeft = .Left

*** Dacă este într-o grilă, salvați înălțimea rândurilor și lățimile coloanei grilei

IF UPPER( .Parent.BaseClass ) = 'COLUMN'

.nOrigRowHeight = .Parent.Parent.RowHeight

FOR lnCol = 1 TO .Parent.Parent.ColumnCount

DIMENSIUNE .nOrigColWidths[lnCol]

.nOrigColWidths[lnCol] = .Parent.Parent.Columns[lnCol].Width

ENDFOR

ENDIF

SE TERMINA CU

Ca și în cazul claselor noastre de casete de text, ne place să putem selecta tot conținutul atunci când caseta de editare se concentrează, așa că verificăm dacă SelectOnEntry = .T. și selectați tot textul dacă este necesar. În plus, poziționăm cursorul la

sfârșitul textului selectat folosind o TASTATĂ „{CTRL+END}”, dacă proprietatea noastră IPositionAtEnd este setată:

Cu asta

DACĂ .SelectOnEntry

.SelStart = 0

.SelLength = LEN( .Valoare )

ENLSE

DACA .lPositionAtEnd

TASTATURA „{CTRL + END}”

ENDIF

ENDIF

SE TERMINA CU

NODEFAULT

Metoda RightClick a casetei de editare își apelează metoda ShowMenu dacă proprietatea IResize este setată la true. Metoda ShowMenu afișează apoi meniul de comenzi rapide (mnuEditBox) și ia acțiunea corespunzătoare în funcție de ceea ce a fost ales din meniu:

LOCAL lcFontString, lcFontStyle, lcFontName, lcFontSize, llBold, llItalic, ;

lnComma1Pos, lnComma2Pos

PRIVAT pnMenuChoice

pnMenuChoice = 0

DO mnuEditbox.mpr

Cu asta

FACE CAZ

*** Dacă a fost selectată mărire, extindeți caseta de editare, dacă nu este așa

*** deja extins

CAZ pnMenuChoice = 1

DACA !.lMaximizat

.Măriți()

ENDIF

*** Dacă a fost selectat micșorare, micșorați caseta de editare dacă este extinsă

CAZ pnMenuChoice = 2

DACA .lMaximizat

.Scurt()

ENDIF

CAZ pnMenuChoice = 3

lcFontStyle = IIF( .FontBold, 'B', '' ) + IIF( .FontItalic, 'I', '' )

*** Obține alegerea utilizatorului de font pentru a utiliza

lcFontString = GETFONT(.FontName, .FontSize, lcFontStyle )

*** analiza proprietățile fontului din șirul returnat

*** după verificare pentru a vă asigura că utilizatorul a selectat ceva

DACĂ ! EMPTY (lcFontString)

lnCommalPos = AT( ',', lcFontString )

lcFontName = LEFT(lcFontString, lnConmalPos - 1)

lnComma2Pos = RAT( ',', lcFontString )

lnFontSize = VAL( SUBSTR( lcFontString, lnCommalPos + 1, ;

lnCorama2Pos

InCommalPos

1))

IcFontStyle = SUBSTR( IcFontString, lnConma2Pos + 1 ) llBold = IIF( 'B' $ lcFontStyle, .T., .F. ) llItalic = IIF( 'I' $ lcFontStyle, .T., .FontName = lcFontName ).

.FontSize = lnFontSize

.FontBold = llBold .FontItalic = llItalic ENDIF

ENDCASE ENDWITH

Funcția getfont() returnează un șir sub forma FontName, FontSize, FontStyle (unde Fontstyle este „B” dacă este aldine, „I” dacă este italic și „BI” dacă este ambele). După analizarea acestui șir de fonturi, convertim caracterele FontStyle, dacă există, în valorile logice așteptate de proprietățile corespunzătoare ale casetei de editare.

Metoda Enlarge este folosită pentru a extinde caseta de editare, dar modul în care controlul este de fapt extins trebuie să țină cont de diferitele tipuri de container în care poate fi plasat.

Am fi putut numi metoda „expand”, dar acesta este tipul de nume descriptiv care poate deveni un cuvânt rezervat într-o versiune ulterioară a Visual FoxPro. Pentru a programa defensiv, avem tendința de a evita folosirea unor potențiale cuvinte rezervate ca metode și nume de câmp. Aceasta a fost o problemă în trecut, deoarece diferite versiuni ale FoxPro au introdus noi comenzi și funcții. Acest lucru este valabil și pentru Visual FoxPro, deoarece au fost introduse noi proprietăți, evenimente și metode. De exemplu, mulți dezvoltatori au folosit odată variabile numite OldVal sau CurVal în FoxPro V2.x - doar pentru a avea codul întrerupt atunci când rulează în Visual FoxPro, unde ambele nume se referă la funcții native.

Prin urmare, codul este oarecum complex:

Cu asta

FACE CAZ

CASE UPPER( .Parent.BaseClass ) = 'COLUMN'

Dacă acesta este CurrentControl într-o coloană grilă, trebuie să extindem celula curentă a grilei înainte de a extinde caseta de editare. Apoi putem ajusta dimensiunea casetei de editare pentru a umple întreaga grilă:

.ExpandGridCell()

.Height = .Parent.Parent.RowHeight

.Width = .Parent.Width

CAZUL SUSUR ( .Parent.BaseClass )

'PAGINĂ'

Acesta este, de asemenea, un caz special, deoarece paginile nu au o proprietate de înălțime. În schimb, PageFrame în sine are o proprietate PageHeight, așa că trebuie să o folosim pentru a extinde caseta de editare:

.Sus = 0

.Stânga = 0

.Height = .Parent.Parent.PageHeight

.Width = .Parent.Parent.PageWidth

Apoi trebuie să ne asigurăm că caseta de editare apare deasupra tuturor celorlalte controale de pe pagină. Apelarea metodei ZOrder cu un parametru de 0 va face acest lucru:

. zComanda(0)

Asta se ocupă de cazurile speciale. Toate celelalte situații pot fi tratate în clauza Altfel, după cum urmează:

IN CAZ CONTRAR

.Sus = 0

.Stânga = 0

.Inaltime = .Parinte.Inaltime

.Width = .Parent.Width

.zComandă(0)

ENDCASE

În cele din urmă, trebuie să setăm steag pentru a indica faptul că caseta de editare este acum într-o stare maximizată:

.lMaximizat = .T.

SE TERMINA CU

Dacă caseta de editare este într-o grilă, manipularea necesită o metodă separată pentru a ajusta atât lățimea coloanei, cât și proprietatea RowHeight a grilei înainte ca caseta de editare să poată fi extinsă. Metoda expandGridCell realizează acest lucru cu doar câteva linii de cod:

LnCol

CU Aceasta.Părinte

Mai întâi, setăm proprietatea ColumnWidth a tuturor coloanelor din grilă la zero:

FOR lnCol = 1 TO .Parent.ColumnCount

.Parent.Columns[lnCol].Width = 0

ENDFOR

Apoi redimensionăm ColumnWidth a coloanei care conține caseta de editare la aceeași lățime ca și grila. De asemenea, setăm RowHeight a grilei la înălțimea grilei în sine (minus HeaderHeight a grilei):

.Width = .Parent.Width

.Parent.RowHeight = .Parent.Height - .Parent.HeaderHeight

În cele din urmă, trebuie să derulăm grila în jos până când rândul curent se află în porțiunea vizibilă a grilei. Codul de mai jos funcționează deoarece porțiunea vizibilă a grilei, după ce este redimensionată, conține doar un singur rând:

FACEȚI CÂND .Parent.RelativeRow # 1

.Parent.DoScroll(1)

ENDDO

SE TERMINA CU

Metoda Shrink a casetei de editare, după cum sugerează și numele, redimensionează caseta de editare la dimensiunile sale originale și conține cod similar cu cel al metodei Enlarge. De fapt, o bună optimizare pentru acest control ar fi adăugarea unei metode „SetParenf care să evalueze containerul părinte, să facă orice ajustări necesare și să returneze înălțimea și lățimea la care ar trebui să fie setată acum caseta de editare. Cu toate acestea, o astfel de metodă ar trebui să fie supraîncărcată pentru a face față atât extinderii, cât și contractării casetei de editare. Abordarea pe care am adoptat-o este atât mai simplă, cât și mai clară. Ca întotdeauna, încercăm să codificăm având în vedere întreținerea.

În cele din urmă, plasăm un mic cod în metoda Valid a casetei de editare pentru a-l micșora în cazul în care utilizatorul decide să navigheze la o înregistrare nouă în timp ce aceasta este maximizată. Majoritatea dezvoltatorilor folosesc un fel de metodă WriteBuffer care este apelată atunci când utilizatorul face clic pe un buton de navigare dintr-o bară de instrumente. Această metodă, în cea mai simplă formă, conține cod similar cu acesta:

IF TYPE ( '_Screen.ActiveForm.ActiveControl.Name' ) = 'C'

*** Pentru grile trebuie să detaliezi și să se concentreze pe controlul conținut

IF UPPER( _Screen.ActiveForm.ActiveControl.BaseClass ) # 'GRID'

_Screen.ActiveForm.ActiveControl.SetFocus()

ENDIF

ENDIF

Acest lucru va determina declanșarea Valid-ului ActiveControl. Evident, se va declanșa și dacă utilizatorul face clic pe un buton de comandă pentru a naviga la o înregistrare nouă. Deci, codul din metoda Valid a casetei de editare asigură că controlul se curăță după sine chiar și atunci când utilizatorul uită. De asemenea, elimină caracterele neimprimabile de la sfârșitul câmpului de memorare dacă utilizatorul a apăsat în mod repetat tasta Enter în încercarea de a părăsi câmpul. Această funcționalitate este invocată atunci când proprietatea lCleanUpOnExit a casetei de editare este setată:

Cu asta

DACĂ .lCleanUpOnExit

.Curăță ()

ENDIF

DACA .lMaximizat

.Scurt()

ENDIF

SE TERMINA CU

Metoda Cleanup funcționează înapoi de la ultimul caracter din câmp și elimină orice caracter a cărui valoare ASCII este mai mică de 33 (primul caracter imprimabil, fără spațiu din setul de caractere ASCII):

LOCAL lcMemoFld, lnChar

*** Acest lucru va scăpa de liniile goale care apar atunci când utilizatorul apasă <Enter>

*** sau alte taste ciudate în loc de <Tab> pentru a ieși din caseta de editare

Cu asta

lcMemoFld = IIF( EMPTY( .Valoare ), '', ALLTRIM( .Valoare ) )

*** Eliminați caracterele nevalide la sfârșitul câmpului MEMO.

*** Buclă înapoi prin câmp și obțineți poziția

*** primul octet care nu este un spațiu, TAB sau CR/LF sau oricare altul

*** caracter cu o valoare ASCII mai mică decât 33:

PENTRU lnChar = LEN( lcMemoFld ) LA 1 PAS -1

IF ASC ( SUBSTR( lcMemoFld, lnChar, 1 ) ) > 32

IEȘIRE

ENDIF

ENDFOR

DACA lnChar > 1

lcMemoFld = LEFT( lcMemoFld, lnChar )

ENDIF

.Valoare = lcMemoFld

SE TERMINA CU
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Combo calendar (Exemplu: CH04. VCX: : cntCalendar)

Această clasă este de fapt un compus conceput pentru a imita comportamentul unei liste derulante pentru introducerea datelor. L-am inclus în setul nostru de controale de bază, deoarece majoritatea aplicațiilor necesită introducerea/actualizarea câmpurilor de dată.

Primul pas în crearea acestui control a fost crearea unei subclase a clasei container native Visual FoxPro ca propria noastră clasă cntBase. Ne-am bazat clasa cntDate pe acest container, mai degrabă decât direct pe clasa de bază Visual FoxPro. La noua noastră clasă am adăugat o casetă de text, un buton de comandă și, în final, un obiect Container OLE. (Am folosit opțiunea Inserare control din dialogul nativ Inserare obiect al containerului OLE pentru a selecta controlul calendarului care este livrat cu Visual FoxPro și pentru a-l adăuga la container.)

- Alege----
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Inserați controlul
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Figura 4.5 Dialog de inserare obiect

În general, proiectăm clasele noastre compuse astfel încât obiectele membre cali metodele containerului să își îndeplinească funcțiile. De exemplu, am fi putut doar să setăm ControlSource a casetei de text din container pentru a se lega de sursa de date subiacentă. În schimb, am adăugat o proprietate cControlSource la cntDate, precum și o metodă SetControlSource. Motivul este că, la momentul proiectării, nu trebuie să detaliem containerul pentru a seta proprietățile individuale ale obiectelor conținute. Astfel, pentru a configura caseta de text conținută, trebuie doar să setăm proprietatea expusă cControlSource pe container și să lăsăm restul la metoda SetControlSource, care este apelată din metoda Init a containerului. Aceeași metodă inițializează, de asemenea, legenda butonului de comandă, astfel încât să înceapă viața ca o săgeată în jos.

S-ar putea să fi făcut acest lucru implicit în buton și, într-adevăr, am încercat să facem acest lucru. Cu toate acestea, testarea controlului după ce a fost aruncat pe un formular a dat rezultate inconsecvente. Uneori ar afișa săgeata în jos dorită, în timp ce alteori ar afișa o săgeată în sus atunci când formularul a fost instanțiat. Nu am găsit o explicație evidentă pentru comportament, dar am stabilit că singura modalitate de a preveni această inconsecvență a fost inițializarea legendei butonului la instanțiere:

Cu asta

.txtDate.ControlSource = .cControlSource

.CmdDrop.Caption = CHR( 25 )

SE TERMINA CU

Funcționalitatea drop-down este implementată prin trei metode personalizate; DropCalendar, PopCalendar și SetCalendar.

DropCalendar face calendarul vizibil și schimbă legenda de pe butonul de comandă de la o săgeată în jos la o săgeată în sus. Este apelat din metoda click a butonului de comandă și metoda KeyPress din caseta de text. Deoarece dorim ca acest control să se comporte ca un combo, calendarul este deschis ori de câte ori utilizatorul apasă fie f4, fie alt+dnarrow:

Cu asta

.OleCalendar.Visible = .T.

.cmdDrop.Caption = CHR( 24 )

SE TERMINA CU

PopCalendar ascunde calendarul deschis atunci când fie se face clic pe butonul de comandă, fie se face o intrare din calendar. De asemenea, actualizează valoarea casetei de text cu valoarea selectată din calendar. În cele din urmă, schimbă pictograma de pe butonul de comandă de la o săgeată în sus la o săgeată în jos:

Cu asta

.txtDate.Value = TTOD( .OleCalendar.Object.Value )

.OleCalendar.Visible = .F.

.cmdDrop.Caption = CHR( 25 )

SE TERMINA CU

SetCalendar sincronizează afișarea datei calendarului cu valoarea conținută în caseta de text. Este apelat din metoda LostFocus a casetei de text în cazul în care calendarul este vizibil când utilizatorul introduce o nouă dată în caseta de text. De asemenea, este numit din metoda Refresh pentru a avea grijă de posibilitatea ca utilizatorul să fi navigat la o înregistrare nouă în timp ce calendarul este vizibil, asigurându-se că atât caseta de text, cât și calendarul afișează aceeași dată. În cele din urmă, apelăm SetCalendar direct din metoda DropCalendar a containerului pentru a ne asigura că data corectă este întotdeauna afișată atunci când calendarul este vizibil:

Cu asta

.OleCalendar.Object.Value = .txtDate.Value

.OleCalendar.Refresh()

SE TERMINA CU

De asemenea, avem nevoie de cod pentru a imita comportamentul nativ al listelor derulante, care pot fi deschise folosind f4 sau <alt>+<dnarrow>. Prindem aceste taste în metoda Keypress a casetei de text, astfel încât să putem face calendarul vizibil atunci când sunt detectate:

*** Verificați F4 și ALT+DNARROW

DACĂ (nKeyCode = -3) SAU (nKeyCode = 160)

CU Aceasta.Părinte

*** Faceți calendarul vizibil dacă nu este

DACĂ ! .OleCalendar.Vizibil

.DropCalendar()

NODEFAULT

ENDIF

SE TERMINA CU

ENDIF
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Figura 4.6 Calendar Combo

Singurul alt cod din această clasă se află în metoda AfterUpdate a controlului calendaristic în sine. Pur și simplu folosește metoda PopCalendar a containerului pentru a actualiza caseta de text cu valoarea selectată și a face calendarul invizibil.
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Butoane de comandă (Exemplu: CH04.VCX::cmdBase)

Pe lângă faptul că permit utilizatorului să introducă date, majoritatea aplicațiilor permit utilizatorului să întreprindă un fel de acțiune. Aici intră în imagine butoanele de comandă sau unele variante, cum ar fi butoanele din bara de instrumente. După cum am discutat în capitolul despre proiectare, făcând clic pe un buton de comandă ar trebui să ofere utilizatorului feedback instantaneu că s-a întâmplat ceva. Puteți face acest lucru cu ușurință dezactivându-l, împiedicând utilizatorul să facă clic pe el în mod repetat și poate blocând sistemul. Am pus această funcționalitate în clasa noastră de bază pentru butonul de comandă. Desigur, este posibil să nu doriți ca fiecare buton de comandă din toate aplicațiile dvs. să prezinte acest tip de comportament. Am planificat din timp și am adăugat proprietatea IDisableOnClick la clasă. În acest fel, făcând clic pe butonul de comandă îl dezactivează numai atunci când această proprietate este setată la true. Am adăugat și o metodă OnClick personalizată la această clasă. Clicul butonului de comandă numește metoda onClick. Orice cod specific de instanță merge întotdeauna în această metodă onClick.

Singurul cod din clasa noastră de bază a butonului de comandă rezidă în metoda sa de clic:

Cu asta

*** Dezactivați butonul dacă este specificat

IF .IDisableOnClick

.Activat = .F.

ENDIF

*** Executați codul personalizat

.OnClick()

*** Reactivați butonul

DACĂ ! .lDisableOnClick

.Activat = .T.

ENDIF

SE TERMINA CU

Observați că această abordare ne permite să dezactivăm un buton și să-l lăsăm dezactivat prin modificarea proprietății sale lDisAbleOnClick în metoda OnClick a unei instanțe. Acest lucru este util pentru butoanele care ar trebui folosite o singură dată și sunt activate numai atunci când sunt îndeplinite anumite condiții externe (de exemplu, un buton „Salvare” sau „Înapoi”).
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Am inteles! Programarea comenzilor logice

Casetele de selectare sunt concepute în primul rând pentru a gestiona datele logice (adică Da/Nu, Pornit/Oprit etc.). Proprietatea Stil determină dacă caseta de selectare este afișată convențional sau ca buton. Când utilizați mouse-ul, există doar două valori posibile pentru o casetă de selectare, un .T. (sau numeric 1) si logicai .F. (numeric 0).

Proprietatea value poate accepta valori logice sau numerice și poate chiar schimba între cele două tipuri, cu condiția ca controlul să nu fie legat. Cu toate acestea, setarea valorii în mod programatic la orice altceva decât .T. sau .F. sau la orice valoare numerică, alta decât 0 sau 1, dă un rezultat strânge, așa cum arată Figura 4.7:

Figura 4.7 Caseta de selectare Comportamentul mafiei programului

Observați că caseta de validare convențională pare să fie bifată și dezactivată în același timp atunci când este specificată o valoare invalidă. Mai rău, pentru caseta de selectare a stilului grafic, nu există nicio diferență aparentă între o valoare pozitivă validă și o valoare invalidă! Cu toate acestea, grația salvatoare este că în toate cazurile și în ciuda aspectului vizual, proprietatea Value returnează valoarea reală.
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Pagini și cadre de pagină (Exemplu: CH04.VCX::pgfBase și CH04.PRG)

Puteți subclasa vizual clasa de bază cadru de pagină a Visual FoxPro în designerul de clasă. Există o singură mică problemă - toate paginile conținute sunt pagini ale clasei de bază Visual FoxPro și nu există nicio modalitate de a subclasa vizual clasa de bază a paginii. Mai rău încă, dacă creați o subclasă pentru cadru de pagină și îi dați, de exemplu, trei pagini, nu o puteți utiliza ulterior pe un formular și eliminați una dintre paginile din designerul de formulare. Veți descoperi, de asemenea, că dacă utilizați acest tip de cadru de pagină subclasat, nici măcar nu puteți schimba numele paginilor într-o instanță a acestuia.

Acest lucru se datorează faptului că nu puteți șterge sau modifica numele obiectelor conținute care aparțin unei clase părinte. Din acest motiv, cel mai bine este, atunci când subclasați cadrul de pagină, să setați proprietatea PageCount la 0 în subclasă. Cu toate acestea, pot exista situații în care trebuie să adăugați metode direct în pagini și nu în cadrul paginii, lucru pe care îl puteți face numai dacă creați o clasă de pagină personalizată.

De fapt, puteți subclasa clasa de bază a paginii. Pur și simplu nu o poți face vizual în designerul clasei. Trebuie făcut în cod. Vestea bună este că aceasta este o sarcină ușoară. Acum pentru veștile proaste - singura modalitate pe care am găsit-o de a folosi paginile noastre personalizate a fost să le adăugăm în cadrul paginii noastre personalizate în timpul rulării. Cadrul de pagină nu are nicio proprietate accesibilă de stocat în clasa pe care să își bazeze paginile și instanțează întotdeauna numărul de pagini necesare din clasa de bază Visual FoxPro Page. Aceasta înseamnă că paginile personalizate sunt practic inutile, cu excepția cazului în care intenționați să utilizați instanțierea întârziată.

Deoparte: ce este „instanțierea întârziată”?

Instanțiarea întârziată este o tehnică în care un obiect este instanțiat doar atunci când este de fapt necesar. În contextul unui cadru de pagină, aceasta înseamnă că, atunci când ați proiectat o pagină, selectați toate controalele acesteia (ctrl+a va face acest lucru) și apoi alegeți „Salvare ca clasă” din meniul Fișier. Aceasta va copia toate controalele într-o clasă de container Visual FoxPro și o va salva ca o clasă nouă. Acum puteți șterge toate comenzile de pe pagină și le puteți adăuga înapoi prin plasarea noii clase de container pe pagină și poziționând-o. Notați valorile proprietăților Sus și Left pentru noul container - veți avea nevoie de acestea mai târziu când adăugați containerul în timpul execuției! În cele din urmă, puteți șterge întregul conținut al paginii, lăsându-l necompletat și repetați procesul pentru toate paginile din cadrul paginii.

Rețineți că trebuie să planificați corect ierarhia obiectelor paginii dvs. pentru ca aceasta să funcționeze. Adăugarea controalelor la un container adaugă, de asemenea, un strat suplimentar de referință, deoarece containerul se află acum între controalele pe care le conține și pagină. Deci, orice referințe la pagină ca:

Acest.Părinte.<ceva>

Trebuie inlocuit cu:

Acest.Parinte.Părinte.<ceva>

să dea socoteală pentru asta. O altă posibilitate este să folosiți o constantă dacă faceți prototip și apoi să salvați clasa containerului. Deci, în loc să vă referiți la This.Parent.<ceva>, puteți #DEFINE Mom This.Parent și vă referiți la celelalte obiecte ca Mom.<Something>. Apoi, trebuie doar să modificați modul în care este definită constanta după ce containerul este salvat ca clasă. În cele din urmă, adăugați cod direct la metoda Activare a fiecărei pagini, astfel:

DACĂ Aceasta.ControlCount = 0

This.AddObject('pagctrls', <controlclass> )

CU Aceasta.pagctrls

.Top = <poziție de sus salvată>

.Left = <poziție din stânga salvată>

.Vizibil = .T.

SE TERMINA CU

ENDIF

Acum, când rulați formularul care conține acest cadru de pagină, fiecare pagină va fi goală atunci când formularul se instanțează, astfel încât formularul va apărea mult mai rapid decât în mod normal (la urma urmei, Visual FoxPro nu trebuie acum să instanțieze și să lege toate controalele de pe " paginile invizibile). Când utilizatorul face clic pe o pagină pentru prima dată, containerul corespunzător, cu toate controalele, este instanțiat. Deși există, evident, o mică întârziere la prima clic pe o pagină, este rareori observată de utilizatori, care în mod normal vor fi foarte fericiți că formularele lor apar atât de mai repede!

Acum reveniți la paginile personalizate

Pentru a folosi pagini personalizate, am creat o clasă personalizată de cadru de pagină (pgfBase) în designerul de clase și am stabilit proprietățile PageCount și ActivePage la 0. Are o metodă personalizată numită SetPages care este apelată din metoda Init și al cărei scop unic este de a elimina paginile clasei de bază ale Visual FoxPro și de a adăuga paginile noastre personalizate în timpul rulării. Iată-l:

LOCAL lnPageCount, lnCnt

*** Asigurați-vă că putem găsi prg-ul care definește paginile personalizate

SETĂ PROC LA CH04 ADITIV

*** Eliminați paginile clasei de bază și adăugați paginile noastre personalizate

Cu asta

lnPageCount = .PageCount

.PageCount = 0

.ActivePage = 0

FOR lnCnt = 1 TO lnPageCount

*** Adăugați unul nou

.AddObject( 'PgBase'+ALLTRIM( STR( lnCnt ) ), 'PgBase' )

ENDFOR

.PageCount = lnPageCount

.ActivePage = 1

SE TERMINA CU

Cu toate acestea, nu ne-am putut gândi la nicio altă proprietate personalizată sau metodă de care avea nevoie noua noastră clasă de cadru de pagină. Comunicarea între pagini poate fi gestionată prin metode personalizate ale cadrului de pagină care le conține. De obicei, acest tip de comunicare este gestionat prin metode de formulare personalizate. Se poate spune că cadrul paginii ar fi de fapt mediatorul mai potrivit.

Apoi, am definit clasa noastră de pagină personalizată în cod. I-am dat o proprietate personalizată numită IRefreshOnActivate. Când este setată la true, pagina este reîmprospătată când devine activă și am adăugat o metodă personalizată numită RefreshPage, care este utilizată pentru a încheia metoda de reîmprospătare a paginii, în același mod în care metoda noastră RefreshForm include metoda de reîmprospătare a formularului. De asemenea, am adăugat proprietatea IReadOnly pentru a permite cadrul paginii noastre să conțină o combinație de pagini editabile și de vizualizare. Pagina noastră personalizată verifică această proprietate în Activare și setează controalele conținute în mod corespunzător folosind o singură linie de cod:

Cu asta

.SetAll( 'Activat', !.lReadOnly )

SE TERMINA CU

Doar pentru a fi flexibili, am adăugat și acest cod la metoda noastră RefreshPage în cazul în care o acțiune întreprinsă de utilizator (făcând clic pe un buton din bara de instrumente, de exemplu) ar putea schimba starea paginii curente. În cele din urmă, i-am dat o proprietate cPrimaryTable pentru a fi folosită pentru acele formulare care actualizează mai multe tabele. În formele de acest tip, majoritatea dezvoltatorilor tind să afișeze tabelele individuale pe pagini separate. Această adăugare a acestei proprietăți la pagină permite codului care este scris să fie mai generic:

DEFINIȚI CLASA PgBase AS Pagina

lRefreshOnActivate = .T.

lReadOnly = .F.

cPrimaryTable = ''

FUNCȚIE Activare

Cu asta

.SetAll( 'Activat', !.lReadOnly )

SE TERMINA CU

ENDFUNC

FUNCȚIE RefreshPage

*** Aceasta este o metodă de șablon asemănătoare cu RefreshForm

*** Dacă trebuie să reîmprospătați această pagină, puneți codul aici în loc de în Refresh

Cu asta

.SetAll( 'Activat', !.lReadOnly )

SE TERMINA CU

ENDFUNC

ENDDEFINE

Se pare că definiția de clasă a cadrului paginii este legată intrinsec de paginile sale conținute la instanțiere. Am creat un mic generator de cadre de pagină (pgfbuild.prg') în încercarea de a adăuga paginile noastre personalizate în cadrul paginii în momentul proiectării. Părea să funcționeze până când am încercat să rulăm formularul. Apoi, spre surprinderea noastră, noile pagini personalizate pe care tocmai le adăugasem au fost înlocuite cu pagini de clasă de bază Visual FoxPro fără un motiv aparent!

Motivul devine evident dacă deschideți un fișier SCX care conține un cadru de pagină ca tabel și îl răsfoiți. Nu există nicio înregistrare pentru niciuna dintre paginile din cadrul paginii și, prin urmare, nu există mijloace pentru cadrul paginii pentru a determina pe ce clasă să își bazeze paginile. În schimb, câmpul de proprietăți pentru obiectul cadru de pagină definește toate proprietățile paginilor conținute. Un alt punct interesant este că, după rularea constructorului nostru, câmpul de proprietăți al cadrului paginii a făcut referire la acele pagini după numele pe care le-am dat și le-a arătat ca fiind paginile noastre personalizate! Dar când ne-am uitat la același formular în designerul de formulare, foaia de proprietăți a enumerat paginile ca pagini de clasă de bază cu numele implicite „Pagina”, „Pagina2” și așa mai departe. (De altfel, același lucru pare să fie valabil și pentru Grile și coloanele lor.

Deși puteți specifica anteturi personalizate pentru coloane și orice control doriți pentru includerea într-o coloană, grilele instanțează întotdeauna coloanele reale direct din clasa de bază Visual FoxPro.)

Dacă doriți să vedeți acest comportament pentru dvs., rulați programul pages.prg care este inclus cu exemplul de cod pentru acest capitol. Setați numărul de pagini din cadrul paginii la un număr mai mare decât zero și rulați generatorul. Când apare fereastra de răsfoire, completați numele și legendele dorite. Închideți și salvați formularul. Când o faci, pages.prg rulează formularul care tocmai a fost salvat.

Prin urmare, concluzia este că, deși puteți defini o clasă de pagină personalizată și puteți utiliza un generator pentru a adăuga pagini bazate pe această clasă la un cadru de pagină în momentul proiectării, modificările pe care le faceți se pierd atunci când cadrul de pagină este instanțiat. Pentru a utiliza pagini bazate pe o clasă personalizată, trebuie să le adăugați în timpul rulării, ceea ce înseamnă că trebuie fie să fie definite cu toate controalele necesare, fie trebuie să adăugați controalele individual (folosind metoda AddObject) sau să utilizați tehnica de instanțiere amânată menționată mai sus .

Intenția noastră aici a fost să vă oferim o modalitate ușoară și convenabilă de a adăuga pagini personalizate la propriul cadru de pagină personalizat în designerul de formulare. Spre dezamăgirea noastră, am descoperit că pur și simplu nu se poate. Dar cel puțin acum știm.
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Capitolul 5 - Combo și liste

„De ce nu ne poate oferi cineva o listă cu lucruri pe care toată lumea le gândește și pe care nimeni nu le spune și o altă listă cu lucruri pe care toată lumea le spune și pe care nimeni nu le gândește?”

(„Profesorul de la masa de mic dejun” de Oliver WendellHolmes, Sr.)

Combo și liste sunt două comenzi foarte puternice care permit utilizatorului să selecteze dintr-un set predeterminat de valori. Folosite în mod corespunzător, ele oferă un mijloc valoros de a asigura validitatea datelor. Folosite necorespunzător, pot fi cel mai rău coșmar al tău. Dacă folosiți o casetă combinată pentru a prezenta utilizatorului mii de articole, vă cereți probleme! În acest capitol, vă prezentăm câteva combinații utile și listăm clase care pot fi folosite pentru a oferi o interfață profesională și rafinată, reducând în același timp semnificativ timpul de dezvoltare. Toate clasele prezentate în acest capitol pot fi găsite în biblioteca de clase CH05.
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Elemente de bază pentru casetele combinate și listă

O privire asupra proprietăților și metodelor casetelor combo și listă și puteți vedea că funcționează intern în același mod. Deși o combinație drop-down vă permite să adăugați elemente la RowSource, nu puteți face acest lucru cu o listă derulantă sau derulantă - sau mai degrabă nu cu controale native ale clasei de bază. Cu nu mai puțin de zece RowSourceTypes posibile și două moduri diferite de a-și gestiona listele interne (ListItemID și ListIndex), aceste clase oferă dezvoltatorului aproape prea multă flexibilitate. Dintre cele zece RowSourceTypes, 0-None, 1-Value, 2-Alias, 3-SQL Statement, 5-Array și 6-Fields sunt cele mai utile. Acest capitol conține exemple de utilizare a acestor șase RowSourceTypes.

Restul de patru, 4-Query (.QPR), 7-Files, 8-Structure și 9-Popup nu sunt acoperite, deoarece sunt fie foarte specifice în natura lor (7-Files și 8-Structure), fie sunt incluse pentru a furniza înapoi compatibilitate (4-Query și 9-Popup) și nu se încadrează în contextul unei aplicații Visual FoxPro.

Colecțiile List și ListItem

Aceste două colecții vă permit să accesați elementele din lista internă a controlului fără a fi nevoie să știți nimic despre RowSource sau RowSourceType specifice. Din acest motiv, aceste colecții și proprietățile și metodele asociate acestora pot fi folosite pentru a scrie un cod foarte generic. Colecția Listă face referire la elementele conținute în listă în aceeași ordine în care sunt afișate. Colecția ListItem face referire la aceleași articole prin ID-urile lor. ItemID este un număr unic, analog unei chei primare care este atribuită articolelor atunci când acestea sunt adăugate în listă. Inițial, indexul și ItemID-ul unui anumit articol din listă sunt identice. Dar, pe măsură ce articolele sunt sortate, eliminate și adăugate, aceste numere nu mai sunt neapărat aceleași.

Tabelul 5.1 Proprietăți și metode asociate colecției List

Proprietate sau metodă 	Ce face?
Listă 	Conține un șir de caractere folosit pentru a accesa articolele din listă după index. Nu este disponibil la momentul proiectării. Citiți numai în timpul rulării.
ListIndex 	Conține indexul articolului selectat din listă sau 0 dacă nu este selectat nimic
NewIndex 	Conține indexul articolului adăugat cel mai recent în listă. Este foarte util atunci când adăugați elemente la o listă sortată. Nu este disponibil la momentul proiectării. Citiți numai în timpul rulării.

TopIndex 	Conține indexul articolului care apare în partea de sus a listei. Nu este disponibil la momentul proiectării. Citiți numai în timpul rulării.
AddItem 	Adaugă un articol la o listă cu RowSourceType 0-none sau 1-value
IndexToItemID 	Returnează ItemID pentru un articol din listă când îi cunoașteți indexul
Removeltem 	Elimină un element dintr-o listă cu RowSourceType 0-none sau 1-value

Tabelul 5.2 Proprietăți și metode asociate cu colecția ListItem

Proprietate sau metodă 	Ce face?
ListItem 	Conține un șir de caractere folosit pentru a accesa articolele din listă după ItemID. Nu este disponibil la momentul proiectării. Citiți numai în timpul rulării.
ListItemID 	Conține ItemID-ul articolului selectat din listă sau -1 dacă nu este selectat nimic
NewItemID 	Conține ItemID-ul articolului adăugat cel mai recent în listă. Este foarte util atunci când adăugați elemente la o listă sortată. Nu este disponibil la momentul proiectării. Citiți numai în timpul rulării.
TopItemID 	Conține ItemI D al articolului care apare în partea de sus a listei. Nu este disponibil la momentul proiectării. Citiți numai în timpul rulării.
AddListItem 	Adaugă un element la o listă cu RowSourceType 0-none sau 1-value
IItemIDToIndex 	Returnează indexul pentru un articol din listă atunci când îi cunoști ID-ul articolului

	
RemoveListItem 	Elimină un element dintr-o listă cu RowSourceType 0-none sau 1-value

Am inteles! Adaugare element

Ajutorul online afirmă că sintaxa pentru această comandă este Control.AddItem(cItem [, nIndex] [, nColumn]). Continuă spunând că atunci când specificați parametrii opționali nIndex și nColumn, noul element este adăugat la acel rând și coloană din control. Dacă specificați un rând care există deja, noul articol este inserat pe acel rând și elementele rămase sunt mutate în jos pe un rând. Sună bine! Din păcate, nu funcționează chiar așa.

Metoda AddItem adaugă într-adevăr un rând întreg la listă. Dacă lista are mai multe coloane și utilizați această sintaxă pentru a adăuga elemente în fiecare coloană, rezultatul nu este cel la care v-ați aștepta. Când utilizați metoda AddItem pentru a popula o combinație sau o listă, adăugați noul articol în prima coloană a fiecărui rând folosind sintaxa Control.AddItem('MyNewValue') . Atribuiți valori coloanelor rămase din acel rând folosind sintaxa control.List[control.NewIndex, nColumn] = „MyotherNewvalue”. Metoda AddListIte~m ^, totuși, funcționează așa cum este anunțat. Asta! este ilustrat clar sub forma ListAndListItem, inclusă cu exemplul de cod pentru acest capitol.

Când se declanșează evenimentele?

Răspunsul la asta, ca de obicei, este „depinde”. Evenimentele se declanșează puțin diferit, în funcție de stilul casetei combinate. Ordinea în care se declanșează depinde și de dacă utilizatorul navighează și selectează elemente cu mouse-ul sau cu tastatura. Este o subestimare grosolană să spunem că înțelegerea modelului de eveniment este importantă atunci când programăm într-un mediu orientat pe obiecte. Acest lucru este absolut esențial atunci când se creează clase reutilizabile, în special clase complexe, cum ar fi casetele combo și listă.

După cum era de așteptat, primele evenimente care se declanșează atunci când controlul devine focalizat sunt When și GotFocus. Acest lucru este valabil pentru casetele combinate din ambele stiluri, precum și pentru casetele de listă. Și aceste evenimente apar în această ordine, indiferent dacă accesați controlul sau faceți clic pe acesta cu mouse-ul. Odată mică particularitate despre combo-ul drop-down este că următorul eveniment care se va declanșa este Combo.Textl.GotFocus! Text1 nu este accesibil dezvoltatorului. Visual FoxPro răspunde oricărei încercări de a-l accesa în cod cu „Membru necunoscut: TEXT1”. Presupunem că text1 este un membru protejat al combo-ului clasei de bază a Visual FoxPro atunci când stilul său este setat la 0 - DropDown Combo.

Următoarea listă conține evenimentele de care veți fi cel mai adesea preocupat atunci când aveți de-a face cu casetele combo și listă. Nu este nicidecum o listă cuprinzătoare, dar toate evenimentele semnificative sunt acolo. De exemplu, evenimentele MouseDown și MouseUp se declanșează înainte de evenimentul Click al obiectului. De dragul simplității și clarității, evenimentele mouse-ului sunt omise.

Tabelul 5.3 Secvența de evenimente combinată și listă

Acțiune 	Combo DropDown ListListBox
		Apăsare taste ( 24, 0 ) Apăsare taste ( 24, 0 )
Derulați prin listă folosind săgeata în jos 	Nu se aplicăInteractiveChangeInteractiveChange
		Faceți clic pe Faceți clic
(fără a arunca mai întâi lista combo-ului)			
		ValidWhen
		Când	
Folosiți mouse-ul pentru a arunca lista 	DropDownDropDownNot Applicable
	Apăsare taste ( 160, 4 ) Apăsare taste ( 160, 4 )	
Folosiți ALT+DNARROW pentru a renunța la lista 			Nu se aplică
	DropDownDropDown	
	Apăsare taste ( 24, 0 ) Apăsare taste ( 24, 0 ) Apăsare taste ( 24, 0 )
Derulați prin lista derulantă folosind 			InteractiveChange
săgeată în jos 	InteractiveChangeInteractiveChangeClick
			Când
	InteractiveChangeInteractiveChangeInteractiveChange
Selectați un element din listă folosind mouse-ul 	ClickClickClick
	ValidValidWhen
	Când Când	
	Apăsare taste ( 13, 0 ) Apăsare taste ( 13, 0 ) Apăsare taste ( 13, 0 )
Selectați un element din listă apăsând pe 	ClickClickDblClick
tasta <ENTER>			
	ValidValidValid
	Valabil		
Ieșiți din control făcând clic în altă parte cu 	LostFocusLostFocusLostFocus
soarecele			

	Text1.LostFocus		
	Apăsare taste ( 9, 0 ) Apăsare taste ( 9, 0 ) Apăsare taste ( 9, 0 )
Ieșiți din control folosind tasta <TAB> 	Valid		
	LostFocusLostFocusLostFocus
	Text1.LostFocus		

Este interesant de remarcat faptul că evenimentul Valid nu se declanșează atunci când controlul își pierde focalizarea fie pentru Lista drop-down, fie pentru ListBox. O consecință a acestui comportament este că orice cod apelat din metoda Valid nu va fi executat atunci când utilizatorul doar parcurge o listă dropDown sau o listă ListBox. În opinia noastră, acesta este un lucru bun. Înseamnă că putem plasa cod care actualizează sursele de date subiacente în metodele numite din metoda Valid a acestor controale și să nu ne facem griji cu privire la murdărirea bufferelor dacă utilizatorul nu a schimbat nimic.

De asemenea, este de remarcat faptul că pentru ComboBoxes, evenimentul Valid se declanșează ori de câte ori utilizatorul selectează un element din listă. (Cu toate acestea, dacă utilizatorul selectează un element din listă făcând clic pe el cu mouse-ul, se declanșează și evenimentul When.) În schimb, pentru ListBoxes, evenimentul Valid se declanșează numai atunci când utilizatorul selectează un articol apăsând tasta Enter sau dublu făcând clic pe el. Este interesant de remarcat că selectarea unui articol cu tasta ENTER declanșează și evenimentul dblClick.

O altă anomalie care merită remarcată este că evenimentul Click din ListBox se declanșează inconsecvent, în funcție de ce tastă este folosită pentru a naviga în listă! Când utilizatorul apasă tastele săgeată în sus și în jos, evenimentul Click se declanșează. Când sunt folosite tastele de pagină sus și pagina în jos, nu se întâmplă.

Cum pot lega casetele mele combo și listă?

Evident, vă legați casetele combo și listă setând proprietatea ControlSource la numele unui câmp dintr-un tabel, cursor sau vizualizare sau la o proprietate de formular. Un prins! de care trebuie să fiți conștient este că puteți lega aceste comenzi numai la surse de date cu caractere, numerice sau nule. Dacă încercați să legați o casetă combinată sau listă la un câmp Data sau DateTime, Visual FoxPro se va plânge și va afișa următoarea eroare în timpul execuției:

Eroare cu <ComboName>-Valoare: tipul de date nu se potrivește.

Dezlegarea obiectului <ComboName>

Dacă trebuie să legați o casetă combo sau listă la un câmp Date sau DateTime, va trebui să recurgeți la un mic truc. În acest caz, nu puteți utiliza RowSourceTypes de 2-Alias sau 6-Fields. Puteți, de exemplu, să setați RowSourceType la 3-SQL Statement și să utilizați o instrucțiune SQL similară cu aceasta ca RowSource:

SELECT DTOC( DateField ) AS DisplayDate, yada, nada, blah FROM MyTable;

ORDER BY MyTable.DateField ÎN CURSOR MyCursor

Lăsați ControlSource necompletat și adăugați acest cod la metoda sa Valid pentru a actualiza câmpul de dată din tabelul de bază:

ÎNLOCUIRE DateField CU CTOD( This.Value ) ÎN MyTable

De asemenea, va trebui să scrieți un cod pentru a actualiza manual valoarea controlului din ControlSource pentru a imita comportamentul unui control legat atunci când îl reîmprospătați. Acest cod din metoda de reîmprospătare a casetei combo sau listă face treaba:

This.Value = DTOC( MyTable.DateField )

Inca o nebunie! care vă poate mușca apare atunci când ControlSource a casetei dvs. combo se referă la o valoare numerică care conține numere negative. Aceasta pare a fi o problemă care apare numai atunci când RowSourceType al controlului este 3-SQL Statement și poate fi de fapt o eroare în Visual FoxPro. Rezultatul este că nimic nu este afișat în porțiunea de text a controlului pentru orice valoare negativă. Cu toate acestea, chiar dacă DisplayValue al controlului este necompletat, valoarea acestuia este corectă. Soluția simplă este să utilizați un RowSourceType, altul decât 3-SQL Statement, atunci când controlul este legat la o sursă de date care poate conține valori negative. Nu este ca și cum ar fi lipsă de alternative.

Deci, pentru ce sunt folosite BoundTo și BoundColumn?

Aceste proprietăți determină modul în care controlul își obține valoarea. Valoarea unei casete combo sau listă este preluată din coloana listei sale interne, care este specificată de BoundColumn. DisplayValue a unei casete combinate, valoarea care este afișată în porțiunea text a controlului, provine întotdeauna din coloana unu! Valoarea sa, pe de altă parte, poate fi luată din orice coloană a listei sale interne. Aceasta înseamnă că puteți afișa text semnificativ, cum ar fi descrierea dintr-un tabel de căutare, în același timp controlul își obține valoarea de la cheia asociată. Nici măcar nu trebuie să afișați această cheie asociată în listă pentru a avea acces la ea.

De exemplu, să presupunem că utilizatorul trebuie să aloce un anumit tip de contact fiecărui contact atunci când este introdus. Tipul de contact corespunzător poate fi selectat dintr-o listă derulantă cu RowSourceType setat la 6-Fields, RowSource setat la " ContactType.CT_Type, CT_Key unde CT_Type este descrierea și CT_Key este cheia asociată în tabelul ContactType. Pentru a configura control, setați mai întâi ColumnCount din Lista dropDown la 2 și ColumnWidths la 150, 0. Apoi setați BoundColumn la 2 pentru a actualiza câmpul legat din tabelul Contacte din valoarea cheii în loc de descriere.

Setarea BoundTo specifică dacă proprietatea valoare a unei casete combo sau listă este determinată de proprietatea List sau ListIndex. Setarea BoundTo contează numai atunci când controlul este legat de o sursă de date numerice. Dacă ControlSource din caseta combo sau listă se referă la date numerice, setarea proprietății BoundTo a controlului la true îi spune Visual FoxPro să actualizeze ControlSource folosind datele din coloana legată a listei interne a controlului. Lăsând BoundTo setat aici la fals, sursa de control va fi actualizată cu ListIndex al controlului, adică numărul de rând al elementului selectat curent.

Cea mai ușoară modalitate de a ilustra modul în care funcționează este utilizarea unui mic cod care simulează modul în care setarea proprietății BoundTo afectează modul în care este actualizată proprietatea Value a controlului:

Cu asta

DACĂ .BoundTo

.Valoare = VAL( .List[.ListIndex, .BoundColumn] )

ALTE

.Valoare = .ListIndex

ENDIF

ENDIF

Cum mă refer la elementele din casetele mele combo și listă?

După cum sa discutat mai devreme, puteți utiliza fie colecția Listă, fie ListItem pentru a vă referi la elementele din caseta dvs. combo sau listă. Marele avantaj al folosirii acestor colecții pentru a accesa elementele din RowSource al controlului este că nu este necesar să știți nimic despre acel RowSource. Puteți utiliza fie proprietatea ListIndex, fie ListItemID pentru a face referire la rândul selectat curent. Dacă nu este selectat nimic din listă, proprietatea ListIndex a controlului este 0 și proprietatea ListItemID este -1. Deci, în metoda Valid a casetei combo sau în metoda LostFocus a casetei listă, puteți verifica dacă utilizatorul a selectat ceva de genul acesta:

Cu asta

DACĂ .ListIndex = 0 && De asemenea, puteți utiliza .ListItemID = -1 aici

MESAGEBOX( 'Trebuie să selectați un articol din listă', 16, ;

„Vă rugăm să faceți o selecție”)

IF LOWER( .BaseClass ) = 'combobox'

RETURN 0 && Dacă acest cod este valabil într-o casetă combinată

ALTE

NODEFAULT && Dacă acest cod este în LostFocus al unui ListBox

ENDIF

ENDIF

SE TERMINA CU

Există, de asemenea, mai multe moduri de a face referire la valoarea unei casete combinate sau listă. Cel mai simplu dintre ele este Control.Value. Când nu este selectat nimic, valoarea controlului este goală. Acesta este ceva de luat în considerare dacă RowSource pentru control permite valori goale. Înseamnă că nu puteți determina dacă utilizatorul a făcut o selecție doar verificând o proprietate de valoare goală.

Deoarece colecțiile List și ListItem sunt matrice, le puteți adresa la fel ca orice altă matrice. (Cu toate acestea, deși puteți aborda aceste colecții ca matrice, nu le puteți manipula direct folosind funcțiile native ale matricei Visual FoxPro, cum ar fi ascaro, adelo sau ALEN() .)

Pentru a accesa elementul selectat din lista internă a controlului atunci când ListIndex-ul său este mai mare decât zero, puteți utiliza:

Control.List[Control.ListIndex, Control.BoundColumn]

în timp ce aceasta face exact același lucru atunci când ListItemID nu este -1:

Control.ListItem [Control.ListItemID, Control.BoundColumn]

De asemenea, puteți accesa elementele din celelalte coloane ale rândului selectat al controlului, referindu-vă la Control.List[Control.ListIndex, 1], Control.List[Control.ListIndex, 2] și așa mai departe până la și inclusiv Control.List[Control.ListIndex, Control.ColumnCount].

Rețineți că, atunci când utilizați colecțiile List și ListItem ale controlului în acest mod, toate elementele din lista internă a controlului sunt stocate ca șiruri de caractere. Dacă RowSource al controlului conține valori numerice, date sau datetime, aceste elemente vor fi întotdeauna reprezentate intern ca șiruri de caractere. Aceasta înseamnă că, dacă doriți să efectuați unele actualizări „din culise” folosind elementele din rândul selectat curent al listei, va trebui mai întâi să convertiți aceste elemente la tipul de date corespunzător. În caz contrar, Visual FoxPro se va plânge, dându-vă o eroare de nepotrivire a tipului de date.

Casetele de listă cu MultiSelect setat la adevărat se comportă puțin diferit. Proprietățile sale ListIndex și ListItemID indică ultimul rând din controlul care a fost selectat. Pentru a face ceva cu toate elementele selectate ale controlului, este necesar să parcurgeți lista sa internă și să verificați proprietatea Selectată a fiecărui element astfel:

CU Thisform.LstMultiSelect

FOR lnCnt = 1 TO .ListCount

DACĂ .Selectat[lnCnt]

*** Elementul este selectat, luați acțiunea corespunzătoare

ALTE

*** Nu este selectat, faceți altceva dacă este necesar

ENDIF

ENDFOR

SE TERMINA CU

Care este diferența dintre DisplayValue și Value?

Casetele combinate sunt controale deosebit de puternice, deoarece vă permit să afișați text descriptiv dintr-un tabel de căutare în timp ce legați controlul la valoarea cheie asociată. Acest lucru este posibil doar pentru că caseta combinată are aceste două proprietăți. Înțelegerea rolului pe care îl joacă fiecare dintre ei poate fi, cel puțin, confuză.

DisplayValue este textul descriptiv care este afișat în porțiunea textbox a controlului. Aceasta este ceea ce vedeți când caseta combinată este „închisă”. DisplayValue al combo-ului vine întotdeauna din prima coloană a RowSource. Pe de altă parte, valoarea combo-ului provine din oricare coloană este specificată ca BoundColumn. Dacă BoundColumn a casetei combinate este coloana unu, valoarea și DisplayValue sunt aceleași atunci când utilizatorul alege un element din listă. Când BoundColumn al controlului nu este coloana unu, aceste două proprietăți nu sunt aceleași. Consultați Tabelul 5.4 de mai jos pentru diferențele dintre aceste două proprietăți în situații diferite.

Tabelul 5.4 Secvența de evenimente combinată și listă

Coloana legată 	ActionDisplayValueValue
			

1 	Selectați un articol din listăColoana 1 a rândului selectatColoana 1 a rândului selectat
1 	Tastați element care nu este în listTyped textEmpty
N # 1 	Selectați un articol din listăColoana 1 a rândului selectatColoana n a rândului selectat
N # 1 	Tastați element care nu este în listTyped textEmpty

Care este diferența dintre „alias” și „câmpuri” RowSourceTypes?

Diferența de bază este că RowSourceType „2-Alias” permite proprietății RowSource să conțină doar un nume de alias. Controlul umple numărul de coloane pe care le are disponibil (definit de proprietatea ColumnCount) citind datele din câmpurile din aliasul specificat în ordinea în care sunt definite. Puteți, totuși, să specificați o listă de câmpuri care urmează să fie utilizate chiar și atunci când RowSourceType este setat la „2-Alias”. În acest caz, nu există nicio diferență practică între setările Câmpuri și Alias.

Când utilizați RowSourceType „6-Fields”, proprietatea RowSource trebuie completată folosind următorul format:

<Nume alias>.<primul câmp>,<al doilea câmp>,.<ultimul câmp>

Când utilizați RowSourceType „2-Alias” sau „6-Fields”, puteți accesa în continuare oricare dintre câmpurile din sursa de date subiacentă - chiar dacă nu sunt incluse în mod specific în RowSource. De asemenea, merită să ne amintim că ori de câte ori se face o selecție, indicatorul de înregistrare din sursa de date subiacentă este mutat automat în înregistrarea corespunzătoare. Cu toate acestea, dacă nu se face o selecție validă, indicatorul de înregistrare este lăsat la ultima înregistrare din sursa de date - nu, așa cum v-ați aștepta, la eofo .

Apropo, atunci când utilizați RowSourceType de „3-SQL”, selectați întotdeauna ÎNTRE un cursor de destinație atunci când specificați RowSource. Dacă nu se specifică un cursor țintă, se va afișa o fereastră de răsfoire! Comportamentul cursorului este același ca atunci când utilizați direct un tabel sau o vizualizare - toate câmpurile din cursor sunt disponibile, iar selectarea unui element din listă mută indicatorul de înregistrare în cursor.
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Cum fac ca casetele mele combo și listă să indice un anumit articol?

Când acestea sunt Controale legate, ele afișează automat selecția specificată de sursele lor de control, astfel încât să nu aveți nevoie să faceți absolut nimic. Dar ce se întâmplă dacă controlul nu este legat sau doriți să afișați o valoare implicită atunci când adăugați o înregistrare nouă? Ca de obicei, există mai multe moduri de a jupui o vulpe. Poate cel mai simplu mod de a realiza acest lucru este:

Thisform.Mylist.IistIndex = 1

Această instrucțiune, fie în metoda Init a formularului, fie imediat după adăugarea unei noi înregistrări, selectează primul element din listă. De asemenea, puteți inițializa o casetă combo sau listă setând direct valoarea acesteia. Cu toate acestea, atunci când inițializați combo-urile și listele care sunt legate la date tamponate, actul de a face acest lucru va murdări tampoanele. Aceasta înseamnă că, dacă aveți o rutină care verifică modificările în înregistrarea curentă folosind GETFIDSTATE () , funcția va detecta „modificarea” în înregistrarea curentă, chiar dacă utilizatorul nu a atins nicio tastă. Pentru a evita efectele secundare nedorite, cum ar fi solicitarea utilizatorului să salveze modificări atunci când crede că nu a făcut niciuna, utilizați setfidstateo pentru a reseta orice câmpuri afectate după inițializarea valorii casetei dvs. combinate sau listă legate.

Un lucru care nu va inițializa valoarea unei casete combo sau listă este setarea proprietății selectate a unuia dintre elementele sale din listă la true în metoda Init a unui formular. Declaratia:

Thisform.Mylist.Selectat[1]

în metoda Init a formularului, nu selectează un element într-o casetă combinată sau listă. Aceeași declarație din metoda Activate a formularului va obține, totuși, rezultatul dorit, așa că bănuim că eșecul declarației atunci când este utilizat în metoda Init a formularului ar putea fi de fapt o eroare.
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Combo de completare rapidă (Exemplu: CH05.VCX::cboQFill)

Un exemplu de metodologie de completare rapidă (și o explicație mai detaliată a exact ceea ce este „umplerea rapidă”) a fost prezentat în Capitolul 4 în Căutarea incrementală TextBox. Această metodologie este și mai ușor de implementat pentru clasa ComboBox. Cutiile combinate Quickfill conferă formelor dumneavoastră un aspect lustruit și profesional. De asemenea, fac sarcina de a selecta un articol din listă mult mai ușoară pentru utilizatorul final. Doar tastați litera „S” în porțiunea de text a combo-ului, iar „Samuel” este afișat. Apoi tastați litera „m” și DisplayValue se schimbă în „Smith”. Chestii foarte tari!

Combo-ul nostru de completare rapidă poate fi folosit indiferent de ce sursă de rând a ComboBox-ului se întâmplă, deoarece operează pe lista internă a controlului. Din acest motiv, ar trebui folosit doar pentru comenzile care afișează, cel mult, câteva zeci de articole. Dacă aveți nevoie de această funcționalitate, dar aveți nevoie să afișați sute de articole, vă trimitem la articolul lui Tamar Granor pe acest subiect în numărul din septembrie 1998 al FoxPro Advisor.

Combo de completare rapidă are o proprietate personalizată numită coldExact. Deoarece căutăm primul articol care se potrivește cu ceea ce a fost introdus până acum, dorim să SETĂM EXACT OFF. În metoda GotFocus a controlului, valoarea inițială a set('exact' >este salvată, astfel încât să poată fi restabilită atunci când controlul pierde focalizarea. Când SET('EXACT' ) = 'OFF', nu este nevoie să folosiți LEFT( ) pentru a compara ceea ce utilizatorul a tastat până acum pentru a găsi cea mai apropiată potrivire din listă. Acest lucru îmbunătățește performanța căutării.

La fel ca în căutarea incrementală TextBox descrisă mai devreme, metoda HandleKey este invocată din metoda InteractiveChange a controlului după ce apăsările de taste au fost deja procesate. De fapt, nu există deloc cod în metoda KeyPress a ComboBox. Metoda InteractiveChange conține doar codul necesar pentru a determina dacă cheia trebuie manipulată:

DACĂ This.SelStart > 0

*** Gestionați caracterele imprimabile, backspace și tastele de ștergere

DACĂ ( LASTKEY() > 31 ȘI LASTKEY() < 128 ) SAU ( LASTKEY() = 7)

This.HandleKey()

ENDIF

ENDIF

Cea mai mare parte a muncii este realizată în metoda HandleKey. Acesta parcurge lista internă a combo-ului pentru a găsi o potrivire pentru ceea ce utilizatorul a introdus până acum:

LOCAL lcSofar, lnSelStart, lnSelLength, lnRow

Cu asta

*** Manipulați tasta Backspace

DACĂ LASTKEY() = 127

.SelStart = .SelStart - 1

ENDIF

*** Salvați punctul de inserare și extrageți ceea ce utilizatorul a tastat până acum

lnSelStart

.SelStart

IcSofar = LEFT( .DisplayValue, lnSelStart )

*** Găsiți o potrivire în prima coloană a listei interne a combo-ului

FOR lnRow = 1 TO .ListCount

IF UPPER( .List[ lnRow, 1 ] ) = UPPER( lcSoFar )

.ListIndex = lnRow

IEȘIRE

ENDIF

ENDFOR

*** Evidențiați porțiunea valorii după punctul de inserare

.SelStart = lnSelStart

lnSelLength = LEN( ALLTRIM( .DisplayValue ) ) - lnSelStart

DACA LnSelLength > 0

.SelLength = lnSelLength

ENDIF

SE TERMINA CU

Acesta este tot ceea ce este necesar pentru o combinație de completare rapidă care funcționează cu orice RowSourceType. Doar plasați-l pe un formular și setați-i RowSourceType, RowSource și ControlSource (dacă trebuie să fie un control legat). Nimic nu ar putea fi mai ușor. Formularul Quickfill.scx, furnizat împreună cu exemplul de cod pentru acest capitol, ilustrează utilizarea acestei clase cu mai multe RowSourceTypes diferite.
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Cum adaug elemente noi în casetele mele combo și listă?

(Exemplu: CH05.VCX: .cboAddNew șiIstAddNew)

{ÿAdăugați articole noi / Editați elementul curent în

Destinație | Italia

Destinație [

Din ¡11/06/95

Το 111/1 7/9Θ

7/99

Buget [

Buget J 5000,1

5000,00

Modalitate de plată

American Express

Diners Club

Delta

Descoperi

MasterCard

Intrerupator

^ln]2£j

P revi ou s I

Apoi eu

Ieșire

Figura 5.1 Adăugați elemente noi și editați elementele existente în casetele combo și listă

Adăugarea unui element nou la o ComboBox cu stil = 0-DropDown Combo este un proces destul de simplu, deoarece evenimentul Valid al controlului se declanșează ori de câte ori se face o selecție din listă și din nou înainte de a pierde focalizarea. Când un utilizator a tastat ceva care nu se află în lista curentă, proprietatea DisplayValue a controlului va păstra datele nou introduse, dar proprietatea Value va fi goală. Un mic cod în metoda Valid a controlului vă permite să determinați dacă utilizatorul a selectat un articol din listă sau a tastat o valoare care nu este în listă. De exemplu, se poate folosi următorul cod:

IF NOT( EMPTY( This.DisplayValue ) ) ȘI EMPTY( This.Value )

*** Utilizatorul a introdus o valoare care nu se află în listă

Cu toate acestea, acest lucru nu va fi de încredere dacă RowSource permite valori goale, așa că o soluție mai bună este să utilizați fie:

IF NOT( EMPTY( This.DisplayValue ) ) ȘI This.ListIndex = O

SAU

Dacă NU( EMPTY( This.DisplayValue ) ) ȘI This.ListitemlD = -1

Apoi, trebuie să luați măsuri pentru a adăuga noul element la RowSource al controlului. Codul folosit pentru a face acest lucru va fi specific unei instanțe, în funcție de modul în care este populat controlul. Dacă RowSourceType al combo-ului este „О-None” sau „1-Value”, utilizați metoda AddItem sau AddListltem pentru a adăuga noua valoare în listă. Dacă RowSourceType este „2-Alias”, „3-SQL Statement” sau „6-Fields”, noul element trebuie adăugat la tabelul de bază și combo sau caseta de listă trebuie solicitată pentru a-și reîmprospăta lista internă. Pentru RowSourceType „5-Array”, adăugați elementul la matrice și reinterogați controlul.

Deși este suficient de simplu să adăugați un element nou la un dropDown Combo, această soluție simplistă poate să nu fie adecvată. Dacă singura cerință este să adăugați o nouă descriere împreună cu cheia ei primară la un tabel de căutare, metodologia discutată mai sus este la îndemâna sarcinii. De cele mai multe ori, însă, a

tabelul de căutare conține mai mult de două coloane. (De exemplu, tabelul de căutare furnizat împreună cu exemplul de cod pentru acest capitol are o coloană pentru un cod definit de utilizator.) Este posibil să fie necesar să fie completate câmpuri suplimentare atunci când un articol nou este adăugat în caseta combinată.

De asemenea, trebuie să luăm în considerare faptul că nu există o modalitate rapidă și ușoară de a adăuga elemente noi la un ListBox. Având în vedere cât de asemănătoare sunt clasele ComboBox și ListBox, considerăm că este adecvat ca acestea să împartă o interfață comună pentru adăugarea de elemente noi. Dacă utilizatorii finali adaugă articole noi în același mod, ei au de reținut un lucru în loc de două. Clasele cboAddNew și IstAddNew oferă această funcționalitate printr-un meniu de comenzi rapide invocat făcând clic dreapta pe control. Acest meniu cu comenzi rapide oferă și funcționalitate de editare. Cel mai adesea, dacă un element dintr-o combo sau o listă este scris greșit, utilizatorul își va da seama când selectează un articol din listă. Este mult mai convenabil să remediați greșeala în acest moment, decât să folosiți un formular separat de întreținere.

Am creat cboAddNew ca o subclasă a cboQuickflll pentru a obține o interfață de utilizator mai consistentă. Toate clasele noastre de casete combinate personalizate moștenesc din clasa noastră combo de completare rapidă, așa că toate se comportă într-un mod similar. Acest tip de consecvență face ca o aplicație să pară intuitivă pentru utilizatorii finali.

Clasele combo și list box „Adăugați nou” au trei proprietăți suplimentare. Proprietatea cForm2Call conține numele formularului de întreținere pentru a instanția atunci când utilizatorul dorește să adauge sau să editeze un articol. Setările proprietăților lAllowNew și lAllowEdit determină dacă pot fi adăugate elemente noi sau dacă pot fi editate elemente existente. Ele sunt, implicit, setate la true, deoarece obiectul acestui exercițiu este de a permite adăugarea de elemente noi și editarea elementelor curente. Cu toate acestea, atunci când am proiectat clasa, am făcut tot posibilul pentru a construi flexibilitate maximă, astfel încât aceste proprietăți pot fi setate pentru a suprascrie acest comportament la nivel de instanță.

Codul care face cea mai mare parte a muncii rezidă în metoda personalizată ShowMenu și este apelat din metoda RightClick a ambelor. În acest exemplu, BoundColumn a combo-ului conține cheia primară asociată cu datele de bază. Se presupune că formularul de întreținere va returna cheia primară după ce adaugă un nou element (Dacă aveți nevoie de funcționalități diferite, codificați-o în consecință.):

LOCAL lnRetVal, loparametri

PRIVAT pnMenuChoice

Cu asta

*** Nu afișați meniul dacă nu putem adăuga sau edita

DACĂ .lAllowNew SAU .lAllowEdit

*** Afișează meniul de comenzi rapide

pnMenuChoice = 0

DO mnuCombo.mpr

DACA pnMenuChoice > 0

*** Creați obiectul parametru și populați-l

loParameters = CREATEOBJECT('Linie')

loParameters.AddProperty('cAction', IIF( pnMenuChoice = 1, 'ADD', 'EDIT' ) ) loParameters.AddProperty('uValue', .Value )

*** Adăugați orice parametri opționali dacă este necesar

.AddOptionalParameters( @loParameters )

*** Acum apelați formularul de întreținere

DO FORM ( .cForm2Call ) CU loParameters LA lnRetVal

lnValue = IIF(lnRetVal = 0, This.Value, lnRetVal )

.Solicitare()

.Valoare = lnValue

ENDIF

ENDIF

SE TERMINA CU

Specificațiile formularului de întreținere depind în mod evident de actualizarea tabelului. Cu toate acestea, orice formular de întreținere apelat din metoda ShowMenu a casetei combo sau listă va trebui să accepte obiectul parametru trecut la metoda sa Init și să folosească informațiile transmise pentru a-și face treaba. De asemenea, va trebui să revină la cheia primară necesară după ce a adăugat cu succes o nouă intrare. În timp ce câmpurile specifice care trebuie actualizate prin acest proces vor varia în funcție de tabelul care este actualizat, procesul în sine este destul de generic. Toate formularele utilizate pentru a adăuga și edita intrări se bazează pe clasa de formulare frmAddOrEdit furnizată împreună cu exemplul de cod pentru acest capitol. Această clasă ilustrează clar modul în care funcționează procesul și puteți verifica Itineraries.scx pentru a vedea cum este apelat acest formular de întreținere de către obiectele IstAddNew și cboAddNew.
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Cum aflu articolele afișate într-o a doua casetă combinată sau listă pe baza selecției făcute în prima? (Exemplu: FilterList.SCX)

Acest lucru este mult mai ușor decât ați putea crede. FilterList.scx, în exemplul de cod pentru acest capitol, nu filtrează doar un ListBox în funcție de ceea ce este selectat într-un ComboBox, ci și ComboBox în funcție de ceea ce este selectat în OptionGroup.

filtrați conținutul unei casete combo orlisi

5.2 Dinamic

RowSourceType preferat pentru controalele fdtered este „3-SQL Statement”, deoarece facilitează configurarea dependenței. Specificăm doar ΉΗΕΕΕ Somefield = ( Thisform.MasterControl .Value ) în clauza WHERE a RowSource al controlului dependent. Apoi, de fiecare dată când controlul dependent este solicitat, acesta este populat cu valorile corespunzătoare.

Sunt două mici neplăceri aici. În primul rând, dacă folosim expresia ThisForm în RowSource al controlului dependent direct în foaia de proprietăți, Visual FoxPro dă tam-tam în timpul execuției. Ne spune că ThisForm poate fi folosit doar într-o metodă. În al doilea rând, deși am putea seta RowSource al controlului dependent în metoda sa Init, acest lucru poate duce și la câteva surprize destul de neplăcute în timpul rulării. Dacă controlul dependent este instanțiat înaintea controlului principal, Visual FoxPro se va plânge că ThisForm.MasterControl nu este un obiect.

Trucul pentru a face acest lucru să funcționeze corect este să puneți codul de inițializare a surselor de rând ale controalelor dependente la locul potrivit. Deoarece controalele formularului sunt instanțiate înainte de declanșarea Init a formularului, o metodă personalizată numită din metoda Init a formularului este un loc bun pentru a pune acest tip de cod. Acesta este exact ceea ce am făcut în metoda SetForm a formularului nostru exemplu:

LOCAL IcRowSource

*** Selectați numai articolele care au un Cat_No egal cu opțiunea selectată

*** în grupul de opțiuni

Toate controalele din formularul eșantion sunt legate de proprietățile formularului. OptionGroup este legat de Thisform.nType. Deoarece această proprietate este inițializată la 1 în foaia de proprietăți, toate controalele conțin o valoare atunci când formularul este afișat pentru prima dată:

lcRowSource = 'SELECT Cat_Desc, Cat_Key, UPPER( Categorii.Cat_Desc ) AS '

lcRowSource = lcRowSource + 'UpperDesc FROM Categorii'

lcRowSOurce = lcRowSOurce + 'WHERE Categories.Cat_No = ( Thisform.nType ) '

lcRowSource = lcRowSource + 'ÎN CURSOR csrCategories ORDER BY UpperDesc'

*** Acum configurați proprietățile combo-ului

CU Thisform.cboCategories

.RowSourceType = 3

.RowSource = lcRowSource

*** Nu uitați să repopulați lista internă a controlului

. Solicitare ( )

*** Inializați-l pentru a afișa primul articol

.ListIndex = 1

SE TERMINA CU

Acum că am inițializat caseta combinată de categorii, putem configura instrucțiunea SQL pentru a fi utilizată ca sursă de rând pentru caseta cu listă de detalii. Dorim să selectăm numai articolele care se potrivesc cu Elementul selectat în caseta combinată:

lcRowSource = 'SELECT Det_Desc, Det_Key, UPPER( Details.Det_Desc ) AS '

lcRowSource = lcRowSOurce + 'UpperDesc FROM Details '

lcRowSource = lcRowSource + 'WHERE Details.De_Cat_Key = ( Thisform.nCategory ) '

lcRowSOurce = lcRowSOurce + 'ÎN CURSOR csrDetalii ORDER BY UpperDesc'

*** Acum configurați proprietățile casetei de listă

CU Thisform.lstDetails

.RowSourceType = 3

.RowSource = lcRowSource

*** Nu uitați să repopulați lista internă a controlului

.Solicitare()

*** Inițializați-l pentru a afișa primul articol

.ListIndex = 1

SE TERMINA CU

Acest cod, în metoda Valid a OptionGroup, actualizează conținutul ComboBox atunci când se face o nouă selecție. De asemenea, actualizează conținutul ListBox, astfel încât toate cele trei comenzi să rămână sincronizate:

CU Thisform

.cboCategories.Requery()

.cboCategories.ListIndex = 1

.lstDetails.Requery()

.lstDetails.ListIndex = 1

SE TERMINA CU

În cele din urmă, acest cod din metoda Valid a ComboBox actualizează conținutul ListBox de fiecare dată când se face o selecție din combo. Acest cod va funcționa la fel de bine dacă este plasat în metoda InteractiveChange a ComboBox. Alegerea metodei, în acest caz, este o chestiune de preferință personală:

CU Thisform

.IstDetails.Requery()

.IstDetails.Listlndex = 1 ENDWITH
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Câteva cuvinte despre tabelele de căutare

Este inevitabil ca o discuție despre casetele combo și listă să se îndrepte către subiectul tabelelor de căutare. La urma urmei, combo-urile și listele sunt cel mai frecvent utilizate pentru a permite utilizatorului să selecteze dintr-un set de valori păstrate într-un astfel de tabel. În general, textul descriptiv din tabelul de căutare este afișat într-un control care este legat de valoarea cheii externe dintr-un fișier de date. Dar care este cel mai bun mod de a structura un tabel de căutare? Ar trebui să existe un singur tabel de căutare universal? Sau ar trebui aplicația să folosească multe tabele de căutare specializate? Încă o dată, răspunsul este „Depinde”. Trebuie să alegeți cea mai potrivită soluție pentru aplicația dvs. Desigur, pentru a lua o decizie în cunoștință de cauză, ajută să cunoașteți avantajele și dezavantajele fiecărei abordări. Deci iată-ne...

Există două avantaje majore în utilizarea unui singur tabel de căutare consolidat. Primul este că, utilizând o singură structură, puteți crea clase de căutare generice, reutilizabile și combinate, care sunt capabile să se populeze. Acest lucru minimizează cantitatea de cod necesară la nivel de instanță, iar mai puțin cod înseamnă mai puțină depanare. Al doilea avantaj al acestei abordări este că aplicația dumneavoastră necesită un singur formular de introducere a datelor pentru menținerea diferitelor căutări. Un formular de întreținere de căutare de două pagini îndeplinește această sarcină destul de bine. Utilizatorul poate selecta categoria de căutare dintr-o listă de pe prima pagină. A doua pagină afișează apoi elementele adecvate pentru categoria selectată. Un buton de editare de pe pagina a doua poate fi apoi utilizat pentru a lansa un formular modal pentru editarea articolului curent. Marele dezavantaj al acestei abordări este că toate căutările au o structură comună. Aceasta înseamnă că, dacă aveți o categorie de căutare care necesită mai multe informații pentru fiecare articol, trebuie fie să creați un tabel de căutare separat pentru acea categorie, fie să adăugați coloane suplimentare la tabelul consolidat care vor fi rareori utilizate.

Utilizarea unui tabel separat pentru fiecare tip de căutare din aplicația dvs. oferă mai multă flexibilitate decât abordarea anterioară. Flexibilitatea sporită aduce, de asemenea, o suprasolicitare sporită. Este mai dificil să creați clase de căutare generice, reutilizabile. Această soluție necesită, de asemenea, mai multe formulare de întreținere a tabelului de căutare.

Folosim o combinație a celor două abordări. Un singur tabel de căutare polivalent funcționează pentru elemente simple care sunt susceptibile de a fi reutilizate în aplicații. Folosim tabele separate pentru căutări specializate care ar putea avea o structură unică. Tabelul nostru standard de căutare este de fapt două tabele: un tabel de antet de căutare care conține categoriile de căutare și un tabel de detalii de căutare asociat care conține articolele pentru fiecare categorie.

Tabelul 5.5 Structura tabelului Lookup Header

Nume câmp 	Data TypeField LengthPurpose
Lh_Key 	Integer 		Primary Key - înregistrarea de identificare unică
Lh_Desc 	Character30Lookup Descrierea categoriei

Lh_Default 	Integer 		Valoare implicită (dacă există) de utilizat din tabelul de detalii de căutare

Tabelul 5.6 Date conținute în tabelul Lookup Header

Lh_Key 	Lh_DescLh_Default
1 	Tipuri de contact1
2 	Tipuri de telefon5
3 	Țări10
4 	tipuri de afaceri23
5 	Relații63
6 	culori	

Tabelul 5.7 Structura tabelului Detalii de căutare

Nume câmp 	Data TypeField LengthPurpose
Ld_Lh_Key 	Integer 		Cheie străină din tabelul de antet de căutare
			

Ld_Key 	IntegerPrimary Key - înregistrarea de identificare unică	
Ld_Code 	Character3Cod definit de utilizator (dacă există) pentru articol
Ld_Desc 	Character30Lookup detaliu descriere articol

Tabelul 5.8 Listarea parțială a datelor conținute în tabelul Detalii de căutare

	Ld_lh_keyLd_KeyLd_CodeLd_Desc
	11 		Client
	12 		Perspectivă
	13 		Concurent
	14 		Personal
	25 		Acasă
	26 		Afaceri
	27 		Fax
	2 	8 		Celular

I------------------------------Il------------------- ---------Il--------------------------Il------------- --------------------------1

2 	9 		Pager
3 	10SUAStatele Unite ale Americii
3 	11UK Regatul Unit
3 	12CANCanada
3 	13GERGermania

După cum puteți vedea din listări, este destul de ușor să extrageți date din tabelul de detalii pentru orice categorie. Deoarece fiecare articol din tabelul de detalii are propria sa cheie unică, nu există ambiguitate chiar dacă aceeași descriere este utilizată în „categorii” diferite.
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Combo și liste de căutare generice (Exemplu: CH05. VCX::cboLookUp și IstLookUp)

Clasele de căutare generice, combinate și reutilizabile, vă permit să implementați tabelul de căutare universal cu foarte puțin efort. Datorită modului în care este structurat tabelul de căutare, se pretează foarte bine la RowSourceType = "3-SQL Statement". Tot ceea ce este necesar sunt câteva proprietăți personalizate și un mic cod pentru a inițializa controlul.

Eu beau

Tip telefon: | Acasă

Nume de contact: | Anita

ConatctType: (personal

Număr de telefon: 10118-948-1810

Tipul afacerii: | tehnologia de informație

Țară:

Italia

Mexic

Norvegia

Regatul Unit

Statele Unite

Anterior

Următorul

Proprietatea cCursorName este folosită pentru a specifica

cursorul care deține rezultatul selectării SQL. Acest lucru este necesar în cazul în care există mai multe instanțe ale controlului pe un singur formular. Fiecare instanță necesită propriul său cursor pentru a menține rezultatul instrucțiunii SQL în RowSource. Dacă se folosește același nume în fiecare caz, cursorul va fi suprascris pe măsură ce fiecare control se instanțează. Veți ajunge cu toate controalele care se referă la versiunea cursorului creată de controlul instanțiat ultimul.

Figura 5.3 Combo de căutare generică și clase cu listă în acțiune

Proprietatea nHeaderKey este utilizată pentru a limita conținutul listei controlului la o singură categorie din tabelul Lookup Header. Acesta conține valoarea cheii primare a categoriei dorite și este folosit pentru a construi clauza WHERE pentru RowSource a controlului.

Metoda de configurare a controlului, invocată la instanțiere, își populează RowSource folosind proprietățile specificate mai sus:

IcRowSource LOCAL

*** Asigurați-vă că dezvoltatorul a configurat proprietățile necesare

ASSERT !EMPTY( This.cCursorName ) MESAJ ;

'cCursorName TREBUIE să conțină numele cursorului de rezultat pentru SQL SELECT!'

assert !empty( This.nHeaderKey ) MESAJ ;

„nHeaderKey TREBUIE să conțină PK-ul unui articol în LookupHeader.dbf!”

*** Configurați RowSource al combo-ului

lcRowSource = 'SELECT ld_Desc, ld_Key FROM LookUpDetail WHERE '

lcRowSource = lcRowSource + 'LookUpDetail.ld_lh_key = ( This.nHeaderKey ) '

lcRowSource = lcRowSource + 'ÎN CURSOR ( This.cCursorName ) '

lcRowSource = lcRowSource + „ORDER BY ld_Desc”

*** Configurați proprietățile combo-ului

Cu asta

.RowSourceType = 3

.RowSource = lcRowSource

.ColumnWidths = ALLTRIM( STR( .Width ) ) + ',0'

. Solicitare ( )

SE TERMINA CU

Utilizarea combinației de căutare este foarte ușoară. Doar plasați-l într-un formular, setați-i ControlSource și completați proprietățile cCursorName și nHeaderKey. Deoarece moștenește din clasa cboAddNew, este, de asemenea, posibil să adăugați noi intrări la tabelul de căutare și să editați elementele existente din mers. Deoarece toate cazurile noastre de căutări generice combo și casete de listă își populează listele din același tabel de căutare generic, putem chiar să punem numele formularului de întreținere a căutării în proprietatea cForm2Call a clasei. Ce ar putea fi mai ușor? Lookups.scx, care este inclus cu exemplul de cod pentru acest capitol, ilustrează cât de ușor este.
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Ce se întâmplă dacă vreau să-mi leg combo-ul la o valoare care nu este

În listă? (Exemplu: CH05. VCX: :cboSpecial și CH05. VCX: . cboNotlnList)

Prima întrebare care îți vine în minte aici este „Atunci de ce folosești o casetă combinată?” Casetele combinate și listă sunt folosite pentru a limita introducerea datelor la un set de selecții predefinite. Permiterea utilizatorului să introducă un articol care nu este în listă încalcă scopul utilizării unei casete combinate în primul rând. Acestea fiind spuse, ne dăm seama că pot exista ocazii în care este nevoie de acest tip de funcționalitate. De exemplu, lefs presupune că un anumit câmp dintr-un tabel este de obicei populat dintr-un set de selecții standard. Cu toate acestea, ocazional, niciuna dintre selecțiile standard nu este potrivită, iar utilizatorul final trebuie să introducă ceva care nu este în listă. În mod clar, dacă elementele non-standard ar fi adăugate în mod regulat la tabelul de căutare subiacent, tabelul ar crește rapid cu intrări rar utilizate. În acest caz, câmpul legat de caseta combinată trebuie să conțină descrierea articolului din tabelul de căutare și nu valoarea cheie. Evident, dacă permitem legarea câmpului la elemente care nu sunt în listă, trebuie să stocăm informațiile în acest mod nenormalizat. Singurul loc pentru a „căuta” astfel de articole ad-hoc este în câmpul legat în sine!

Figura 5.4

Clasă combo specială care se leagă de elemente care nu sunt în lisi

Deoarece un astfel de combo poate fi folosit numai atunci când tabelul la care este legat nu este normalizat, suntem tentați să folosim o casetă combinată cu RowSourceType = 1-None și proprietatea Sorted setată la true. Acest cod, în metoda Init a combo-ului, îl populează cu tipurile care există în prezent în tabelul nostru „Oameni”:

LOCAL InSelect

LnSelect = SELECTO

SELECTAȚI CTYPE DISTINCT DIN Persoane ORDINAȚI DUPĂ cType ÎN CURSOR CSrTypes

DACĂ CALITATE > 0

SELECTAȚI csrTypes

SCANĂ

This.AddItem( csrTypes.cType )

ENDSCAN

ENDIF

SELECTARE ( lnSelect )

Apoi, în metoda Valid a combo-ului, am putea verifica dacă utilizatorul a tastat o valoare care nu este în listă și am putea adăuga:

Cu asta

DACĂ !( UPPER( ALLTRIM( .DisplayValue ) ) ) == UPPER( ALLTRIM( .Value ) ) )

.AddItem ( .DisplayValue )

ENDIF

SE TERMINA CU

Deși este adevărat că acest cod funcționează, există câteva probleme fundamentale. În primul rând, dacă tabelul sursă are un număr mare de înregistrări, interogarea inițială ar putea provoca o întârziere semnificativă atunci când formularul este instanțiat. În al doilea rând, acest lucru nu va rezolva problema inițială. Dacă sunt adăugate întotdeauna elemente noi în listă, lista va continua să crească, făcând dificil pentru utilizator să selecteze o intrare. De asemenea, această ilustrație nu permite utilizatorului să distingă care elemente sunt selecțiile „standard” din listă și care sunt doar intrări ad-hoc.

Clasa noastră cboSpecial, constând dintr-o casetă de text, casetă de listă și buton de comandă în interiorul unui container, rezolvă problema. Caseta de text este controlul legat. Caseta listă este lăsată nelegată și RowSource și RowSourceType sunt populate pentru a afișa selecțiile standard. Clasa conține cod pentru a oferi casetei de text funcționalitatea de „umplere rapidă” și pentru a sincroniza afișajul în controalele incluse.

Porțiunea casetă de text a clasei folosește acest cod în metoda KeyPress pentru a face porțiunea din listă vizibilă atunci când utilizatorul apasă alt+dnarrow sau f4. De asemenea, se asigură că lista devine invizibilă atunci când sunt apăsate tastele TAB sau ESC:

*** Au fost apăsate <alt>+<DNARROW> SAU <F4>

DACĂ nKeyCode = 160 SAU nKeyCode = -3

Acesta este.Parent.DropLi st()

nodefault

ENDIF

*** Au fost apăsate <TAB> sau <ESC>

DACĂ nKeyCode = 9 SAU nKeyCode = 27

This.Parent.lstSearch.Visible = .F.

ENDIF

Singurul alt cod din caseta de text rezidă în metoda sa InteractiveChange și singurul său scop este de a invoca metoda de căutare a containerului:

*** Dacă a fost introdus un caracter valid, lăsați metoda de căutare a părintelui să se ocupe de el

DACĂ This.SelStart > 0

DACĂ ( LASTKEY() > 31 ȘI LASTKEY() < 128 ) SAU ( LASTKEY() = 7)

This.Parent.Search()

ENDIF

ENDIF

Metoda de căutare a containerului face apoi munca necesară:

LOCAL lcSofar, lnSelStart, lnSelLength, lnRow

Cu asta

CU .txtqFill

*** Manipulați tasta Backspace

DACĂ LASTKEY() = 127

.SelStart = .SelStart - 1

ENDIF

*** Obțineți valoarea introdusă până acum

lnSelStart = .SelStart

lcSofar = LEFT( .Value, lnSelStart )

SE TERMINA CU

*** Găsiți o potrivire în coloana #1 a porțiunii de listă a acestui control

CU .lstSearch

*** Resetați indexul listei în cazul în care avem tip ion ceva care nu este

*** În listă

.ListIndex = 0

FOR lnRow = 1 TO .ListCount

IF UPPER( .List[ lnRow, 1 ] ) = UPPER( lcSoFar )

.ListIndex = lnRow

*** Sincronizați conținutul casetei de text cu ceea ce este selectat

*** În listă

This.txtQfill.Value = .Value

IEȘIRE

ENDIF

ENDFOR

SE TERMINA CU

CU .txtqFill

*** Evidențiați porțiunea valorii după punctul de inserare

.SelStart = lnSelStart

lnSelLength = LEN( ALLTRIM( .Value ) ) - lnSelStart

DACA LnSelLength > 0

.SelLength = lnSelLength

ENDIF

SE TERMINA CU

SE TERMINA CU

Porțiunea casetei de listă a controlului conține cod în metodele KeyPress și InteractiveChange pentru a actualiza valoarea casetei de text cu valoarea acesteia atunci când utilizatorul selectează din listă. Acest cod este necesar în ambele metode, deoarece apăsarea fie a tastei Enter, fie a barei de spațiu pentru a selecta un element din listă va provoca declanșarea evenimentului său KeyPress, dar nu va declanșa evenimentul InteractiveChange. Selectarea unui element cu mouse-ul declanșează evenimentul InteractiveChange, dar nu declanșează KeyPress, chiar dacă lastkeyo returnează

valoarea 13 indiferent dacă este folosit mouse-ul sau tasta Enter. Acest cod, din metoda InteractiveChange a casetei de listă, este similar, dar nu identic cu codul din metoda KeyPress:

DACĂ LASTKEY() # 27

This.Parent.TxtQFill.Value = This.Value

*** un clic de mouse dă o valoare LASTKEY() de 13 (la fel cum apăsați enter)

DACĂ LASTKEY() = 13

Aceasta.Vizibil = .F.

This.Parent.txtQfill.SetFocus()

ENDIF

ENDIF

Singurul alt cod din porțiunea cu listă a clasei rezidă în metoda GotFocus. Acest cod invocă pur și simplu metoda RefreshList a containerului pentru a se asigura că elementul selectat din caseta de listă este sincronizat cu valoarea casetei de text atunci când caseta de listă este făcută vizibilă:

LnRow LOCAL

CU This.lstSearch

.ListIndex = 0

FOR lnRow = 1 la .Listcount

IF UPPER( ALLTRIM( .List[ lnRow ] ) ) = ;

UPPER( ALLTRIM( This.txtQFill.Value ) )

.ListIndex = lnRow

IEȘIRE

ENDIF

ENDFOR

SE TERMINA CU

Unul dintre dezavantajele clasei container este că nu poate fi utilizat cu ușurință într-o rețea. Pentru a îndeplini această cerință, am creat clasa combo cboNotInList. După cum puteți vedea în Figura 5.4, când lista din grilă este abandonată, primul element este evidențiat atunci când DisplayValue nu este în listă. De aceea preferăm să folosim clasa cboSpecial atunci când nu trebuie să fie plasată într-o grilă. Când DisplayValue nu este în listă, observați că nu este evidențiată nicio selecție a clasei compuse.

Clasa combo cboNotInList folosește același truc pe care l-am folosit la construirea casetei de text numerice din Capitolul 4. Deși poate fi un control legat, îl dezlegam în culise în metoda sa Init și îi salvăm ControlSource în proprietatea personalizată cControlSource:

IF DODEFAULT()

Cu asta

.cControlSource = .ControlSource

.ControlSource = ''

SE TERMINA CU

ENDIF

Metoda RefreshDisplayValue a combo-ului este apelată din ambele metode Refresh și GotFocus pentru a-și actualiza DisplayValue cu valoarea câmpului la care este legată. Este interesant de remarcat că este necesar să invocați această metodă doar din GotFocus al combo-ului atunci când combo-ul este într-o grilă:

LOCAL lcControlSource

Cu asta

DACĂ ! EMPTY( .cControlSource )

IcControlSource = .cControlSource

.DisplayValue = &lcControlSource

ENDIF

SE TERMINA CU

În cele din urmă, metoda UpdateControlSource a combo-ului este apelată din Valid pentru (ai ghicit) să-și actualizeze sursa de control din DisplayValue:

LOCAL lcAlias, lcControlSource

Cu asta

DACĂ ! EMPTY( .cControlSource )

lcAlias = JUSTSTEM( .cControlSource )

IF UPPER( ALLTRIM( lcAlias ) ) = 'ACEASTAFORMĂ'

lcControlSource = .cControlSource

STORE .DisplayValue TO &lcControlSource

ALTE

ÎNLOCUIȚI ( .cControlSource ) CU .DisplayValue IN ( lcAlias )

ENDIF

ENDIF

SE TERMINA CU

Consultați NotInList.scx în exemplul de cod pentru acest capitol pentru a vedea ambele clase în acțiune.
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Cum dezactivez articole individuale dintr-o combo sau listă?

Prima noastră reacție este „De ce afișați articole într-o casetă combinată pe care utilizatorul nu are voie să le selecteze?” Cu siguranță pare să fie în contradicție cu raționamentul de bază pentru utilizarea unei casete combinate în primul rând: să permită utilizatorului să aleagă dintr-o listă predefinită de intrări permise. Dacă utilizatorului nu i se permite să selecteze un articol, ce naiba face în caseta combo sau listă pentru început? Din nou ne dăm seama că pot exista scenarii valide care necesită o astfel de funcționalitate. De exemplu, codurile CPT utilizate în aplicațiile medicale pentru a defini tranzacțiile cu variații și codul ICD-9 utilizat pentru a defini diagnosticele standard se pot modifica în timp. Nu se poate pur și simplu șterge codurile care nu mai sunt utilizate, deoarece detaliile istorice pot fi legate de aceste coduri învechite. La afișarea acestor date istorice, ar fi util să afișați codul inactiv ca fiind dezactivat. În acest fel, o casetă combinată legată de codul ICD-9 nu și-ar „pierde” valoarea afișată deoarece codul nu ar putea fi găsit în lista de control. Nici utilizatorului i-ar fi permis să o selecteze pentru o intrare curentă, deoarece ar fi dezactivată.

Figura 5.5 Elemente dezactivate într-o casetă combinată

Pentru a dezactiva un element dintr-o casetă combo sau listă, trebuie doar să adăugați o bară oblică inversă la începutul șirului care definește conținutul primei coloane din RowSource a controlului. Cu toate acestea, aceasta funcționează numai pentru RowSourceTypes „О-None”, „1-Value” și „5-Array”. Formularul Disabledltems.sex, furnizat împreună cu exemplul de cod pentru acest capitol, oferă un exemplu pentru o combinație cu RowSourceType „5-Array”. Acest cod din metoda Init a casetei combinate populează matricea și dezactivează elementele numai dacă data din tabelul de bază indică că acest element este inactiv. Acest tip de logică poate fi folosit și pentru a dezactiva anumite elemente pe baza valorii unui câmp logic care determină dacă elementul este încă activ:

SELECT IIF( !EMPTY( PmtMethods.pm_dStop ), '\'+pm_Desc, pm_Desc ) AS pm_Desc, ;

pm_Key EROM PmtMethods ORDER BY pm_Desc INTO ARRAY This.aCuprins

Această cerere()

Am putea la fel de ușor să setăm caseta combinată cu a.RowSourceType de „О-None”, să setăm proprietatea Sorted la true și să o populam astfel:

leltem LOCAL

SELECTAȚI PmtMethods

SCANĂ

IcItem = IIF( EMPTY( dStop ), dStop, '\' + dStop )

This.AddItem(lcItem)

ENDSCAN
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Cum creez o casetă listă cu casete de selectare precum cea afișată de Visual FoxPro când selectez „Vizualizare bare de instrumente” din meniu? (Exemplu: CH05.VCX::lstChkBox)

Ați observat vreodată că casetele de listă au o proprietate Imagine? Puteți găsi această proprietate listată în fila de aspect a foii de proprietate. Tehnic vorbind, proprietatea imagine aparține cu adevărat elementelor casetei de listă, mai degrabă decât casetei de listă ca obiect. În esență, puteți manipula proprietatea Picture a elementului Listl curent și o puteți seta la o casetă bifată dacă este selectată și la o casetă simplă dacă nu este.

Canada

Germania

Olanda

Figura 5.6 Caseta de selectare multiplă folosind casetele de validare

□ K

Casetele de listă de acest tip prezintă un alt comportament nestandard care necesită programare specială. De exemplu, făcând clic pe un element selectat din această casetă de listă, îl deselectează. Apăsarea barei de spațiu acționează și ca o comutare pentru selectarea și deselectarea elementelor. Acest lucru este mult mai convenabil decât combinațiile standard CTRL+CLICK și CTRL+SPAȚIU, utilizate în mod normal pentru selectarea mai multor elemente într-o casetă de listă.

Această clasă listă necesită o proprietate de matrice personalizată pentru a urmări elementele selectate. Nu putem folosi pur și simplu proprietatea nativă Selected, deoarece nu este întotdeauna setată în modul așteptat. De exemplu, apăsarea barei de spațiu selectează elementul curent. Dar proprietatea Selected a articolului nu este setată la adevărat decât după finalizarea metodei KeyPress. Să presupunem că vrem să manipulăm această proprietate în metoda KeyPress a casetei de listă. This.Selected[ This.ListIndex ] ar returna false chiar dacă tocmai am fi apăsat pe bara de spațiu pentru a selecta elementul curent! Puteți vedea dilema. Și devine și mai complicat când

încercând să utilizați tasta pentru a comuta proprietatea Selectată a articolului. Soluția simplă și simplă este să ne menținem propria listă de selecții curente asupra cărora avem control total. Acest lucru este implementat folosind o proprietate personalizată a matricei (aSelected), inițializată în metoda Reset a controlului, care este apelată din Init:

Cu asta

*** șterge toate selecțiile

*** Dacă este necesar un alt comportament în mod implicit, puneți-l aici și apelați acest lucru

*** metoda din orice loc în care conținutul casetei de listă trebuie resetat

.ListIndex = 0

DIMENSIUNE .aSelectat[.ListCount]

.aSelectat = .F.

SE TERMINA CU

Metoda SetListItem este apelată din metodele Click și KeyPress din caseta de listă. Deoarece evenimentul Click se declanșează atât de frecvent (de fiecare dată când utilizatorul defilează prin listă folosind tastele cursorului), trebuie să ne asigurăm că apelăm metoda SetListItem doar atunci când utilizatorul face clic pe un articol. Facem acest lucru verificând LASTKEY() = 13. De asemenea, este invocat doar din metoda KeyPress atunci când utilizatorul apasă fie tasta ENTER, fie BARA DE SPAȚIU. Această metodă setează rândul specificat în matricea personalizată care urmărește selecțiile casetei de listă și setează proprietatea Imagine a articolului la imaginea corespunzătoare pentru starea sa curentă:

Cu asta

DACĂ .ListIndex > 0

*** Elementul este selectat în prezent, așa că deselectați-l

DACĂ .aSelectat[.ListIndex]

.Picture[.ListIndex] = „Box.bmp”

.aSelected[.ListIndex] = .F.

ALTE

*** Elementul nu este încă selectat, deci selectați-l

.Picture[.ListIndex] = „CheckBx.bmp”

.aSelected[.ListIndex] = .T.

ENDIF

ENDIF

SE TERMINA CU

Comportamentul standard al Visual FoxPro este de a deselecta toate elementele din caseta de listă atunci când se concentrează. Se pare că acest comportament implicit reseta și toate imaginile din listă. Deoarece nu vrem că caseta noastră cu selecție multiplă să prezinte acest tip de amnezie, numim metoda personalizată Refresh.Li.sl din metoda GotFocus:

LnItem LOCAL

Cu asta

FOR lnItem = 1 TO .ListCount

.Picture[ lnItem ] = IIF( .aSelected[ lnItem ], 'CheckBx.bmp', 'Box.bmp' )

ENDFOR

SE TERMINA CU
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O listă de mutare cless (Exemplu: CH05.VCX::cntMover)

Listele de mutare, cum ar fi clasa de casete cu listă „căsuță de bifare” discutată mai sus, sunt mai ușor de utilizat decât caseta de listă cu selecție multiplă. Deși par a fi controale complexe, este relativ simplu să creați o clasă de listă de mutare generică, reutilizabilă. Clasa noastră de listă de mutare constă dintr-un container cu o casetă de listă pentru a păstra setul de articole din care utilizatorul poate alege și un altul care va fi populat cu articolele selectate. De asemenea, conține patru butoane de comandă pentru a muta elementele între cele două liste. Barele de mutare din lista de destinații sunt activate pentru a oferi flexibilitate maximă. Dacă ordinea articolelor selectate este critică pentru funcționalitatea listei de mutatori, aceasta oferă un mecanism pentru ca utilizatorul să-și ordone selecțiile. Metoda ResetList a containerului, care populează inițial listele, este singura metodă specifică instanței. Formularul MoverList.scx, furnizat împreună cu exemplul de cod pentru acest capitol, utilizează această metodă pentru a popula lista sursă a mutatorului din tabelul nostru „PmtMethods”:

Cu asta

.IstSource.Clear()

.IstDestination.Clear()

SELECTAȚI Țări

SCANĂ

.IstSource.Additem( c_Desc )

ENDSCAN

SE TERMINA CU

Clasa noastră de listă de mutatori nu este în niciun caz ultimul cuvânt în care se mută, dar vă va oferi ceva pe care să vă dezvoltați.

Figura 5.7 Mișcare simplă

lisi

Butoanele de comandă nu sunt singura modalitate de a muta articole între cele două liste. Făcând dublu clic pe un articol, îl elimină din lista curentă și îl adaugă la celălalt. Elementele selectate pot fi, de asemenea, trase dintr-o listă și aruncate în cealaltă. De fapt, nu contează cum sunt mutate elementele între liste. Toată mișcarea se realizează prin invocarea metodei Moveltem a containerului și prin trecerea acesteia la o referință la lista sursă pentru mutare. Există un cali la această metodă de la DblClick și

Metodele DragDrop pentru fiecare dintre casetele de listă, precum și metoda OnClick a celor două butoane de comandă, cmdMove și cmdRemove:

LPARAMETERS toSource

LnItem LOCAL, către Destinație

Deoarece acestei metode i se transmite o referință de obiect listei sursă, putem folosi această referință pentru a determina care este lista de destinații:

Cu asta

IF toSource = .lstSource

toDestination = .lstDestination

ALTE

toDestination = .lstSource

ENDIF

SE TERMINA CU

*** Blocați ecranul pentru a evita efectele secundare vizuale care distrag atenția

*** care rezultă din mutarea articolului (articolelor)

THISFORM.LockScreen = .T.

Acum parcurgem lista sursă pentru a adăuga fiecare element selectat la lista de destinații și apoi îl scoatem din lista sursă. Pe măsură ce elementele sunt eliminate din lista sursă, proprietățile lor ListCount sunt reduse cu unu. Deci folosim o buclă do while în loc de o buclă for pentru a avea mai mult control asupra când indexul în lista sursă este incrementat. Îl creștem numai atunci când elementul curent din listă nu este selectat pentru a trece la următorul:

lnItem = 1

CU toSource

DO WHILE lnItem <= .ListCount

DACĂ .Selectat[ lnItem ]

laDestination.AddItem( .List[ lnItem ] )

.RemoveItem( lnItem )

ALTE

lnItem = lnItem + 1

ENDIF

ENDDO

SE TERMINA CU

*** Nu uitați să deblocați ecranul!

THISFORM.LockScreen = .F.

Implementarea funcționalității drag and drop necesită puțin mai mult cod. Pentru a realiza acest lucru, am adăugat proprietățile nMouseX, nMouseY și nDragThreshold în container. Metoda MouseDown a casetelor de listă conținute setează proprietățile nMouseX și nMouseY la coordonatele curente atunci când butonul stâng al mouse-ului este apăsat. Acest lucru se face pentru a preveni tragerea unui element atunci când utilizatorul tocmai a făcut clic pentru a-l selecta. Operația de glisare nu începe decât dacă mouse-ul a mutat cel puțin numărul de pixeli specificat de proprietatea nDragTheshold. Metoda StartDrag a containerului, apelată din metoda MouseMove din casetele de listă, verifică dacă mouse-ul a fost mutat

suficient pentru a începe operația de tragere. Lista de apeluri transmite o referință la obiect și coordonatele curente ale mouse-ului acestei metode:

LPARAMETERS toList, tnX, tnY

Cu asta

*** Începeți operația de glisare numai dacă mouse-ul s-a mișcat

*** cel puțin numărul minim de pixeli

IF ABS ( tnX - .nMouseX ) > .nDragThreshold SAU ;

ABS( tnY - .nMouseY ) > .nDrag Threshold

toList.Drag()

ENDIF

SE TERMINA CU

În cele din urmă, proprietatea DragIcon a listei de la care a provenit operația de glisare trebuie schimbată în pictograma corespunzătoare. Când cursorul se află pe o porțiune a ecranului care nu permite ca elementul să fie aruncat, dorim să afișăm cercul familiar cu o bară oblică în interiorul acestuia care înseamnă universal „NU!” Facem acest lucru apelând metoda Changelcon a containerului din metoda DragOver a listei. Această metodă, după cum sugerează și numele, schimbă doar pictograma de glisare în pictograma corespunzătoare:

LPARAMETERS toSource, tnState

DACĂ tnState = 0

*** permis să cadă

toSource.DragIcon = THIS.cDropIcon

ALTE

DACĂ tnState = 1

*** nu este permis să cadă

toSource.DragIcon = THIS.cNoDropIcon

ENDIF

ENDIF

Nu numai că lista de mutare este mult mai ușor de utilizat decât caseta de listă cu selecție multiplă, dar oferă și aplicației un aspect și o senzație mai profesională - fără prea mult efort suplimentar.
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Ce se întâmplă dacă trebuie să afișez sute de articole în caseta mea combinată?

În acest caz, o casetă combinată este prea lentă, deoarece trebuie să-și completeze întotdeauna lista internă cu toate elementele din sursa de date subiacentă. Dacă am fi capabili să combinăm eficiența unei rețele (care poate încărca date după cum este necesar) cu capacitatea de căutare incrementală a casetei noastre combo quickfdl, am avea soluția perfectă. Din fericire, folosind compoziție, putem face exact asta și am creat o clasă pentru acest control „ComboGrid” care folosește o casetă de text, un buton de comandă și o grilă ca componente principale.

Construcția este similară cu cea descrisă pentru clasa noastră "cboSpecial" - folosită pentru a permite legarea unui control la o valoare care nu este inclusă în lista internă. Principala diferență este că, în loc de caseta de listă folosită în controlul anterior, acum folosim o grilă pentru funcționalitatea drop-down. Este necesară o manipulare specială la nivelul containerului pentru a se asigura că totul funcționează fără probleme, dar tehnicile sunt aceleași.

Acest control a fost inițial scris și postat ca o contribuție „FreeHelp” la forumul CompuServe Visual FoxPro, iar mai târziu a fost folosit ca bază pentru un articol în revista FoxTalk. Pentru o discuție completă despre proiectarea și implementarea acestui control, consultați „Acum îl vedeți, acum nu îl vedeți”, un articol din ediția din iulie 1999 a FoxTalk. Figurile 5.8 și 5.9 arată cele două încarnări ale grilei combo:

Figura 5.8 ComboGrid inactiv

В · 	.		
1 B's Beverages 	-ii	
Alfreda Futterkiste 	Justin Trouble030-0076545
Ana Trujillo Emparedados y helados Revista Rita 		(5) 555-3745
Antonio Moreno Taquería 	Johnathon Davies	
În jurul cornului 	Thomas Hardy(71) 555-6750
B's Beverages 	Victoria As h worth	
Berglunds snabbkop 	Editați rândul curent01 21-5564-4455
BlauerSee Delicatessen 	Har Sortați după această coloană0621-08924
Blondel père et fils 	Fret Set Filler88.60.15.32
Faceți clic dreapta pe Grid pentru a edita intrarea curentă 	Qear Filler 		I

Figura 5.9 ComboGrid activ

Note de lansare pentru clasa ComboGrid (Clasa: CboGrid.vcx, Exemplu de formular: FrmCGrd.scx)

Creat de: Marcia G. Akins și Andy Kramek și plasat în domeniul public în februarie 1999.

Această clasă este concepută pentru a utiliza o grilă în locul unei casete combinate VFP standard pentru un volum mare de date sau pentru a introduce date în mai mult de un câmp de tabel de căutare, folosit pentru a completa meniul derulant. Clasa constă dintr-o casetă de text, un buton de comandă și o grilă în interiorul unui container. Grila este în mod normal invizibilă, iar clasa arată și se comportă la fel ca o casetă combinată VFP standard.

Clasa este controlată de 7 proprietăți, după cum urmează:

Tabelul 5.9 Proprietăți personalizate ComboGrid

Funcția de proprietate	
CAlias 	Numele tabelului de utilizat ca RecordSource pentru Grid
CColSource 	Gomma listă separată de nume de câmpuri pentru coloanele din Grid
CControlSource 	pentru caseta de text (dacă este necesar să fie legată)
CkeyField 	Câmp de utilizat pentru a seta valoarea TextBox
	

CtagName 	Etichetă de utilizat în cAlias
LAddNewEntry 	Determină dacă intrări noi sunt adăugate la Tabelul Grid, precum și la sursa de control pentru caseta de text
NColCount 	Numărul de coloane de afișat în grilă

Este disponibilă o singură metodă la nivel de Instanță, astfel încât datele să poată fi citite din grilă după ce se face o selecție, de exemplu, pentru a completa alte câmpuri din formular:

Tabelul 5.10 Metode personalizate ComboGrid

Metodă 	Funcția
RefreshControls 	numită de Grid AfterRowColChange() și de KeyPress în QuickFill TextBox

Există patru moduri de utilizare a acestui control, în funcție de setarea proprietăților cControlSource și lAddNewEntry, după cum urmează:

• 	cControlSource:= "" și lAddNewEntry = .F. Caseta de text NU este legată și, deși căutarea incrementală va funcționa și pot fi introduse date noi în caseta de text, înregistrările noi nu vor fi adăugate la tabelul de bază al grilei.

• 	cControlSource:= "" și lAddNewEntry = .T. Caseta de text NU este legată și pot fi introduse date noi în caseta de text, înregistrările noi vor fi adăugate la tabelul de bază al grilei. Coloanele suplimentare pot avea date introduse făcând clic dreapta în celula corespunzătoare.

• 	cControlSource:= <Specified> și lAddNewEntry = .F. Caseta de text este legată și își va citi valoarea inițială din tabelul specificat și va scrie modificările la acel câmp înapoi în tabel. Înregistrările noi nu vor fi adăugate la tabelul de bază al grilei.

• 	cControlSource:= <Specified> and lAddNewEntry = .T. Caseta de text este legată și își va citi valoarea inițială din tabelul specificat și va scrie modificările la acel câmp înapoi în tabel. Coloanele suplimentare pot avea date introduse făcând clic dreapta în celula corespunzătoare.

Mulțumiri

Mulțumiri se datorează lui Tamar Granor pentru metodologia QuickFill pe care a publicat-o în numărul din septembrie 1998 al FoxPro Advisor și lui Paul Maskens, care a oferit inspirația pentru containerul și grila cu autodimensionare.

În urma unei sugestii a lui Dick Beebe, ComboGrid a fost îmbunătățită pentru a include un meniu cu clic dreapta în grila derulantă. În funcție de setări, puteți fie să sortați după coloana selectată, fie să editați rândul selectat curent. Dacă niciunul nu este adecvat, meniul nu apare.

Pentru a activa editarea, trebuie setată proprietatea lAddNewEntry a Containerului. Pentru a permite sortarea sursei de date a grilei, trebuie să aveți o etichetă index numită exact la fel ca și câmpul folosit ca sursă de control pentru coloană. Dacă aceasta nu este practica ta normală, probabil că ar trebui să o iei în considerare oricum.

Declinarea răspunderii autorului

Ca întotdeauna, am încercat să facem ComboGrid-ul fără totuși, dar am plasat această clasă de control în Domeniul Public „ca atare”, fără nicio garanție implicită sau dată. Nu ne asumăm răspunderea pentru orice pierdere sau daune rezultate din utilizarea acestuia (corectă sau necorespunzătoare). Tot codul sursă este inclus în subdirectorul CboGrid al exemplului de cod al acestui capitol, așa că nu ezitați să-l modificați, modificați sau îmbunătățiți pentru a vă satisface nevoile specifice.
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Capitolul 6 - Grile: comenzile neînțelese

„A fi mare înseamnă a fi înțeles greșit”. (Eseuri, „Self-Reliance” de Ralph Waldo Emerson)

Grila este cel mai defamat control din Visual FoxPro. Mulți experți și-au exprimat public opinia că nu folosesc niciodată, în nicio circumstanță, o grilă pentru introducerea datelor. Deși este dificil de îmblânzit, grila poate fi folosită foarte eficient în acest scop în situația potrivită. O grilă este, de asemenea, cea mai bună alegere atunci când vine vorba de afișarea foarte rapidă a unor cantități mari de date. În acest capitol vă vom prezenta câteva tehnici încercate și testate pe care le puteți folosi pentru a obține mai mult din grilele dvs.

Când lucrați cu grile, primul lucru de reținut este că o grilă nu este o foaie de calcul, deși poate arăta ca una. Într-adevăr, există un singur rând într-o grilă. Restul se face cu fum si oglinzi. Nu vă puteți referi la celula din a treia coloană a celui de-al zecelea rând al grilei. Dar vă puteți referi la al treilea câmp din a zecea înregistrare a RecordSource al grilei. În general, dacă trebuie să accesați valori într-o anumită celulă de grilă, cel mai bun pariu este să obțineți acele informații din câmpul din sursa de date subiacentă.

O grilă afișează de obicei date din sursa de date pe care o specificați în proprietatea RecordSource. Cu toate acestea, chiar dacă nu specificați o sursă de înregistrare, puteți afișa în continuare date în grilă. Dacă există un cursor deschis în zona de lucru selectată curent, grila își va extrage datele de acolo! Proprietatea RecordSourceType a grilei specifică cum se deschide sursa de date care populează controlul grilei. De obicei alegem implicit, „2-Alias”, deoarece este cel mai util în general.
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Când se declanșează evenimentele? (Exemplu: GridEvents.scx)

Capacitatea de a utiliza în mod eficient grilele se bazează pe înțelegerea când se declanșează evenimentele. Sunt și niște probleme! de notat înainte de a începe. Iată ce se întâmplă când grila se concentrează pentru prima dată:

• 	Grila este Când se declanșează evenimentul

• 	Evenimentul When al CurrentControl din prima coloană se declanșează

• 	Evenimentul GotFocus al CurrentControl din ActiveColumn se declanșează

• 	Evenimentul AfterRowColChange al grilei se declanșează

Numai acest lucru are câteva implicații importante. Dacă plasați cod în metoda AfterRowColChange a rețelei crezând că se declanșează numai după ce mutați din celula curentă, gândiți-vă din nou! Se declanșează ori de câte ori grila se concentrează. Apropo de asta, ai observat că grilei îi lipsește o metodă GotFocus, deși are o metodă SetFocus?

Rețineți că atunci când grila devine focalizată, ActiveColumn va fi aceeași coloană care era activă când grila a pierdut anterior focalizarea. Prima dată când intrați într-o grilă, CurrentControl din prima coloană va deveni ActiveCell. Să presupunem că apoi navigați la a treia coloană grilă înainte de a face clic pe alt obiect formular. Data viitoare când grila devine focalizată, ActiveColumn, în mod implicit, va fi a treia coloană.

Lucrurile se întâmplă puțin diferit atunci când grila își pierde focalizarea. Și apropo, chiar dacă grila își pierde focalizarea, nu are metoda LostFocus. Interesant nu?

• 	Evenimentul Valid al grilei se declanșează

• 	Evenimentul BeforeRowColChange din Grid se declanșează

• 	Evenimentul Valid al CurrentControl din ActiveColumn se declanșează

• 	Evenimentul LostFocus al celulei active din grilă se declanșează

Odată ce grila este focalizată și utilizați tastatura pentru a naviga între celulele din grilă, evenimentele se declanșează astfel:

• 	Evenimentul KeyPress al CurrentControl din ActiveColumn se declanșează

• 	Evenimentul BeforeRowColChange al grilei se declanșează

• 	Evenimentul Valid al CurrentControl din ActiveColumn se declanșează

• 	Evenimentul LostFocus al incendiilor celulelor active

• 	Evenimentul When al CurrentControl din coloana pe care o mutați la incendii

• 	Evenimentul GotFocus al noilor incendii de celule active

• 	Evenimentul AfterRowColChange al grilei se declanșează

Când folosiți mouse-ul pentru a naviga între celulele dintr-o grilă, evident evenimentul KeyPress nu se declanșează. Evenimentele rămase se declanșează în exact aceeași ordine ca atunci când se utilizează tastatura pentru a naviga. Cu toate acestea, atunci când utilizați mouse-ul, evenimentul Click al celulei nou-active se declanșează imediat după AfterRowColChange al grilei. Această secvență este aceeași chiar și atunci când CurrentControl din ActiveColumn a grilei este o casetă combinată în loc de o casetă de text.

Am inteles! Incendiile valide ale rețelei înainte de valabilitatea controlului curent

Observați că atunci când treceți de la o grilă la un alt obiect din formular, Valid-ul grilei se declanșează înainte de Nalidul celulei active. Acesta este un bug. În mod normal, v-ați aștepta să utilizați metoda Valid a controlului pentru a determina dacă acel control poate pierde focalizarea. Cu toate acestea, atunci când un control este conținut într-o grilă, există două niveluri la care funcționează focalizarea. În primul rând, între control și alte controale care sunt, de asemenea, în grilă. În acest context lucrurile se comportă normal.

În al doilea rând, este problema ce obiect de formă are focalizarea. Acest bug te va mușca atunci când focalizarea este mutată între grilă și alt obiect. După cum v-ați aștepta, metoda Valid a grilei este cea care determină dacă grila își poate pierde focalizarea. Cu toate acestea, deoarece Valid al grilei este apelat înainte de cel al oricărui control conținut, un control conținut nu poate împiedica grila să-și piardă focalizarea, chiar dacă propria validare a eșuat.

Acest lucru poate și va permite introducerea datelor proaste în grilă. Din fericire, există o soluție ușoară, care asigură că Valid-ul grilei apelează și returnează în mod explicit rezultatul validării oricărui control conținut. Deci, dacă caseta de text din prima coloană a grilei are cod în Valid, această linie din metoda Valid a grilei se ocupă de problemă:

RETURN This.Column1.Text1.Valid()
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Care este diferența dintre ActiveRow și

RelativeRow? (Exemplu: ActiveRow&RelativeRow. scx)

O grilă are două seturi de proprietăți care pot fi folosite pentru a se referi la rândul și coloana actuale. The

Proprietățile ActiveRow și ActiveColumn conțin valori „absolute”. Să presupunem că grila este utilizată pentru a afișa toate câmpurile din toate înregistrările RecordSourcei sale în ordine naturală. În această situație, ActiveRow al grilei este același cu numărul de înregistrare și ActiveColumn este același cu numărul câmpului.

Cu toate acestea, dacă RecordSource nu este în ordinea naturală, ActiveRow deține offset-ul înregistrării curente față de prima înregistrare din ordinea curentă. Dacă un subset de câmpuri este afișat în grilă, ActiveColumn deține decalajul pozițional al câmpului curent față de primul câmp din acest subset.

Pe de altă parte, proprietățile RelativeRow și RelativeColumn se referă la poziția rândului și coloanei curente în raport cu porțiunea vizibilă a grilei. Pare destul de simplu, nu-i așa?

Ei bine, nu tocmai. Cele de mai sus sunt valabile doar atâta timp cât grila este controlul activ. Când un alt obiect formular este controlul activ, aceste proprietăți sunt resetate la zero. În plus, valorile lor sunt de încredere numai atunci când celula activă se află în porțiunea vizibilă a grilei. Dacă o celulă din grilă are focus și barele de defilare verticale sunt folosite pentru a derula grila, astfel încât celula activă să nu mai fie vizibilă, atât ActiveRow, cât și RelativeRow sunt setate la zero! Când această celulă reapare în grilă, RelativeRow și ActiveRow sunt resetate la valorile lor corecte. Valoarea deținută de ActiveColumn a grilei nu se modifică, chiar și atunci când celula activă este derulată în afara vederii. În această situație, RelativeColumn a grilei conține valorile corecte dacă interpretați această valoare ca fiind decalajul față de prima coloană din porțiunea vizibilă a grilei. Cu alte cuvinte, prima coloană „invizibilă” imediat din stânga primei coloane vizibile din grilă se află la offset 0. Coloana imediat din stânga celei de la offset 0, este la offset -1 și așa mai departe.

Deci, ce înseamnă toate acestea? Nu multe, într-adevăr. Anomaliile sunt interesante, dar nu vor avea niciun efect asupra modului în care folosim aceste proprietăți. Proprietățile ActiveRow și RelativeRow sunt foarte utile atunci când dorim să oferim grilei noastre un comportament special. De exemplu, comportamentul implicit al tastei Tab este de a muta focalizarea pe următoarea coloană din rândul curent al grilei. Să presupunem că doriți să mutați focalizarea pe aceeași coloană din rândul următor. Nu puteți face acest lucru doar prin creșterea ActiveRow a grilei. În schimb, trebuie să utilizați proprietatea RelativeRow a rețelei pentru a determina când să invocați metoda DoScroll. Exemplul de cod pentru realizarea acestei sarcini apare mai târziu în acest capitol. Am inclus, de asemenea, o clasă de casetă combinată grilă care permite tastelor cursorului să traverseze grila atunci când combo-ul este „închis”. Acest comportament este implementat și prin utilizarea acestor proprietăți.

Am inteles! ActiveColumn nu vă spune cu adevărat care este coloana activă

Proprietatea ActiveColumn sună ca și cum ar trebui să ne spună care coloană a grilei este cea accesată de utilizator și, într-un fel, o face. Cu toate acestea, acest lucru nu este foarte util, deoarece ne spune doar poziția coloanei active în prezent în grilă, nu care dintre coloane este activă în prezent.

Personal, credem că dacă ActiveColumn al grilei este 1, ar fi util dacă aceasta ar însemna că Grid.Columns[1] a fost coloana activă. Acest lucru este, de fapt, adevărat numai dacă coloanele grilei nu sunt mobile și dacă dezvoltatorul nu a rearanjat coloanele în designerul de formulare înainte de a seta proprietatea mobilă a coloanei la fals.

Luați, de exemplu, o grilă care conține cinci coloane mobile. Dacă coloanele sunt rearanjate astfel încât să fie în această ordine:

.Coloane[4] .Coloane[5] .Coloane[1] .Coloane[2] .Coloane[3]

iar utilizatorul introduce în caseta de text conținută în .Columns[5], ActiveColumn a grilei este 2. Aceasta este aceeași valoare ca și proprietatea ColumnOrder a .Columns[5]. Pentru a face ceva semnificativ cu ActiveColumn a grilei, trebuie să scriem cod pentru a afla care este coloana activă:

PENTRU FIECARE loColumn IN This.Columns

IF loColumn.ColumnOrder = This.ActiveColumn

*** Aceasta este coloana activă

*** Obțineți o referință sau faceți tot ce trebuie făcut cu ea aici

IEȘIRE

ENDIF

ENDFOR
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Cum evidențiez rândul actual al grilei? (Exemplu:

CH06. VCX::grdBase)

Când vă uitați la foaia de proprietăți a grilei, veți vedea o proprietate numită HighlightRow sub fila aspect. Prima dată când l-ați văzut, probabil v-ați gândit că lăsarea acestei proprietăți la setarea implicită ar evidenția rândul curent al grilei. Gresit! La prima vedere, se pare că setarea acestei proprietăți la adevărat sau la fals nu face nimic. Acest lucru este, de asemenea, incorect. Dacă setați HighlightRow la adevărat, veți observa că chenarul rândului curent al grilei este evidențiat. Nu foarte util, nu-i așa? Vă sugerăm să setați această proprietate la false în clasa grilă de bază, deoarece lăsând-o setată la adevărat degradează performanța.





	CompanieContactȚarăTelefon
	Altre ds FutterkisteJustin TroubleGerm any030-0074321
	Ana Trujillo Emparedados y heladosRita MagazineMexic(5) 555-4729
	Antonio Moreno TaqueríaJohnathon DaviesMexic(5) 555-3932
	În jurul cornuluiThomas HardyUK(71) 555-7788
	Berglunds snabbkópÎncercați acesta Suedia0921-12 34 65
	Blauer Vezi DelicatessenHannaMoosGerm any0621-08460
	Blondel père et filsFrédérique Cite auxFrance88.60.15.31
	Bólido Comidas preparadasMartin SommerS pa in(91) 555 22 82
	Bon app'Laurence LebihanFranţa91.24.45.40
	Piețe cu dolari de jos Elizabeth LincolnCanada(604) 555-4729
				
	Cactus Comidas para llevar Patricio SimpsonArgentina(1) 135-5555

Anterior

Următorul

Ieșire

rândul curent al grilei

Figura 6.1 Evidențiați

Din fericire, este o chestiune destul de simplă să adăugați această funcționalitate la grila clasei de bază. Grila necesită două proprietăți personalizate pentru a realiza acest lucru. Primul, inițializat la zero, este nRecNo. Acesta va păstra numărul înregistrării în prezent în ActiveRow al grilei. Al doilea, inițializat la false, este lAbout2LeaveGrid. Este folosit pentru a reseta în mod corespunzător înălțimea atunci când navigăm în grilă și pentru a ne asigura că grila rămâne evidențiată atunci când focalizarea se mută către un alt obiect formular. Acest cod, în metoda Init a grilei, va evidenția rândul curent al grilei în cyan:

LOCAL IcForeColor, IcBackColor

IcForeColor = 'IIF( RECNO( This.RecordSource ) = This.nRecNo, '

IcForeColor = IcForeColor + „RGB( 0, 0, 128 ), RGB( 0, 0, 0 ) )”

IcBackColor = 'IIF( RECNO( This.RecordSource ) = This.nRecNo, '

IcBackColor = IcBackColor + 'RGB( 0, 255, 255 ), RGB( 255, 255, 255 ) )

Cu asta

.nRecNo = RECNO( .RecordSource )

.SetAll( 'DynamicForeColor', IcForeColor, 'COLUMN' )

.SetAll( 'DynamicBackColor', IcBackColor, 'COLUMN' )

Pentru a schimba evidențierea atunci când rândul curent al grilei se modifică, acest cod este necesar în metoda When a fiecărui control din fiecare coloană a grilei:

CU Acest.Părinte.Părinte

.nRecNo = RECNO( .RecordSource )

SE TERMINA CU

De asemenea, trebuie să setăm proprietatea lAbout2LeaveGrid a rețelei la true în metoda Valid și la false în When. Singurul alt cod necesar este în metoda BeforeRowColChange a grilei:

DACĂ !Acest.lAbout2LeaveGrid

Aceasta.nRecNo = 0

ENDIF

Copyright 2000 de către Marcia Akins, Andy Kramek și Rick Schummer Toate drepturile rezervate

Cum pot împiedica derularea grilei când utilizatorul accesează ultima coloană?

Dacă sunteți tipul de pacient, este posibil să faceți acest lucru vizual în designerul de formulare. Puteți să vă asigurați cu mare atenție că lăsați un pixel între marginea din dreapta a ultimei coloane a grilei și marginea dreaptă a grilei. Cu toate acestea, cei mai mulți dintre noi avem lucruri mai importante și nu avem răbdare pentru acest gen de prostii.

Am adăugat o metodă personalizată numită SetGrid la grila clasei de bază pentru a o configura corect atunci când este instanțiată. Ne asigurăm că grila se dimensionează corect prin adăugarea unui mic cod la metoda SetGrid a grilei noastre de bază. Acest cod este executat numai atunci când grila nu are bare de defilare orizontale, deoarece se bazează pe determinarea care este ultima coloană din porțiunea vizibilă a grilei. În mod clar, atunci când grila poate fi derulată pe orizontală, nu există o „ultima coloană” fixă.

Aceasta aduce un alt punct. Grilele care defilează orizontal demonstrează un design prost al interfeței. Considerăm că toate informațiile prezentate într-o grilă ar trebui să fie imediat vizibile pentru utilizatorul final. Acest lucru este deosebit de important în cazul grilelor de introducere a datelor. În situațiile de introducere a datelor cu capul în jos, este dificil pentru utilizatorii finali să-și păstreze locul și distrag atenția atunci când informațiile defilează pe și în afara ecranului. De asemenea, necesită să vă jucați pentru a vizualiza informații relevante atunci când acestea sunt ascunse vizualizării într-o grilă care se derulează pe orizontală:

*** Dacă grila nu derulează pe orizontală, asigurați-vă că coloanele sunt dimensionate

*** corect, astfel încât grila să nu defileze atunci când deplasați tabulatorul din ultima coloană

Cu asta

IF INLIST( .ScrollBars, 0, 2 )

*** Calculați lățimea totală a tuturor coloanelor

lnTotColWidth = 0

FOR lnCnt = 1 TO .ColumnCount

*** Supliment pentru lățimea acestei coloane

lnTotColWidth = lnTotColWidth + .Columns[ lnCnt ].Width + 1

*** află dacă aceasta este ultima coloană

IF .Columns[ lnCnt ].ColumnOrder = .ColumnCount

lnLastColumn = lnCnt

ENDIF

ENDFOR

*** Supliment pentru lățimea barei de defilare (dacă este necesar)

lnTotColWidth = lnTotColWidth + IIF( .ScrollBars = 2, ;

SISTEMRIC( 5 ), 0 ) + 2

*** Supliment pentru marcajul de ștergere (dacă este necesar)

lnTotColWidth = lnTotColWidth + IIF( .DeleteMark, 8, 0 )

*** Supliment pentru marca de înregistrare (dacă este necesar)

lnTotColWidth = lnTotColWidth + IIF( .RecordMark, 10, 0 )

*** Redimensionați ultima coloană pentru a vă asigura că grila este complet umplută

.Columns[ lnLastColumn ].Width = .Columns[ lnLastColumn ].Width + ;

( .Width - lnTotColWidth )

ENDIF

SE TERMINA CU
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Cum creez anteturi cu mai multe linii? (Exemplu:

CH06. VCX: :grdBigHeaders și grdMLHeaders)

Personal, credem că anteturile cu mai multe linii sunt prea multe probleme și sunt mult prea restrictive. Acestea fiind spuse, am creat o clasă grilă care le folosește. Pentru a utiliza această clasă, toate coloanele de grilă trebuie să aibă proprietățile lor redimensionabile și mobile setate la false. Acest lucru se datorează faptului că clasa setează proprietatea HeaderHeight a grilei la zero și înlocuiește antetul cu etichete care stau deasupra grilei. Deoarece aceste etichete nu se redimensionează sau nu se mută, clasa grilă nu permite derularea orizontală.

anteturi într-o grilă statică

6.2 Grilă multilinie

Clasa noastră grilă antet multilinie are două metode noi: ReplaceHeaders, care creează etichetele deasupra grilei și WhiteShadow, care creează efecte vizuale pentru a face ca aceste etichete să semene mai mult cu anteturile native Visual FoxPro. De asemenea, am adăugat un cod la metoda noastră SetGrid pentru a ne asigura că coloanele din această clasă de grilă nu pot fi mutate sau redimensionate:

LnCnt LOCAL

DODEFAULT()

Cu asta

FOR lnCnt = 1 TO .ColumnCount

.Coloane[ lnCnt ].Mobil = .F.

.Coloane [ lnCnt ].Redimensionabil = .F.

ENDFOR

*** Configurați anteturile cu mai multe linii

.ReplaceHeaders()

SE TERMINA CU

Metoda ReplaceHeaders, după cum sugerează și numele, înlocuiește antetul coloanei grilei cu etichete. Rețineți că HeaderHeight a grilei trebuie să fie setat suficient de mare în designerul de formulare pentru a găzdui legenda cu mai multe linii. Această valoare este folosită pentru a seta înălțimea etichetei în metoda ReplaceHeaders:

LOCAL lnLeft, li, lnVSBWidth, lcName, InDelRecBlobWidth, ;

InTop, lnHeaderHeight, lnOrdinal

Cu asta

LnLeft = IIF (.DeleteMark, 8,0) && Offset pentru ștergere marcaj

LnLeft = lnLeft + IIF (.RecordMark,10,0) && Offset pentru marcajul de înregistrare lnDelRecBlobWidth = lnLeft lnHeaderHeight = .HeaderHeight

lnTop = .Sus + 1 && salvare poziţia de sus a grilei

*** Resetați înălțimea antetului grilei la zero, pentru a preveni interferența acestuia

.HeaderHeight = 0

*** Deplasați grila în jos în funcție de înălțimea antetului

.Sus = .Sus + lnHeaderHeight

*** Reglați înălțimea grilei în funcție de înălțimea antetului

.Height = .Height - lnHeaderHeight

lnVSBWidth = SISTEMRIC (5) + 1 && Obține lățimea barei de defilare verticală

*** scanare rapidă prin coloane pentru a găsi ordinea coloanelor

LOCAL ARRAY laSequence[ .ColumnCount ]

FOR li = 1 TO .ColumnCount

laSequence[ li ] = This.Columns[ li ].ColumnOrder

ENDFOR

FOR li = 1 TO .ColumnCount

*** găsiți referința de coloană ordinală din numărul secvenței de ordine a coloanei lnOrdinal = ASCAN( laSequence, li )

lcName = "dHeader" + LTRIM( STR( lnOrdinal ) )

This.Parent.Addobject(lcName, „Label”)

WITH EVAL ("Acest.Parinte." + lcName)

.BackStyle = 1

.BorderStyle = 1

.WordWrap = .T.

.Vizibil = .T.

.Alinierea = 2 && Alinierea la centru arată cel mai bine

.Caption = This.Columns[ lnOrdinal ].Controle[ 1 ].Caption

.BackColor = This.Columns[ lnOrdinal ].Controls[ 1 ].BackColor

FontName = This.Columns[ lnOrdinal ] 	.Controls[ 1 ].Fontname
FontSize = This.Columns[ lnOrdinal ] 	.Controls[ 1 ].FontSize
FontBold = This.Columns[ lnOrdinal ] 	.Controls[ 1 ].FontBold

.Height = lnHeaderHeight

.Width = This.Columns[ lnOrdinal ].Width + 2

.Left = This.Left + lnLeft

.Top = lnTop

This.Columns[ lnOrdinal ].Controle[ 1 ].Caption = SPACE(0)

Acest.WhiteShadow (.stânga, .sus, .înălțime, .lățime)

lnLeft = lnLeft + This.Columns[ lnOrdinal ].Width + 1

SE TERMINA CU

ENDFOR

*** Adăugați blob deasupra semnului de înregistrare / ștergere

DACĂ lnDelRecBlobWidth > 0

CU .Părinte

.Addobject („shpDelRecBlob”, „Shape”)

.shpDelRecBlob.Backcolor = RGB (192.192.192)

.shpDelRecBlob.Height = lnHeaderHeight

.shpDelRecBlob.Width = lnDelRecBlobWidth + 1

.shpDelRecBlob.Left = This.Left

.shpDelRecBlob.Top = lnTop

.shpDelRecBlob.Visible = .T.

CU .shpDelRecBlob

Acest.WhiteShadow (.stânga, .sus, .înălțime, .lățime)

SE TERMINA CU

SE TERMINA CU

ENDIF

*** Adăugați blob deasupra barei de defilare verticală

DACĂ .Scrollbars = 2

CU .Părinte

.Addobject („cmdScrollBlob”, „ConmandButton”)

CU .cmdScrollBlob

.Activat = .F.

.Height = lnHeaderHeight

.Width = lnVSBWidth

.Left = This.Left + This.Width - lnVSBWidth

.Top = lnTop

.Caption = SPAȚIU (0)

.Vizibil = .T.

SE TERMINA CU

SE TERMINA CU

ENDIF

SE TERMINA CU

Această clasă este reutilizabilă și nu necesită mult cod specific de instanță. Este, totuși, limitat la grile statice. Ne dăm seama că odată ajuns într-o lună albastră este posibil să aveți nevoie de o grilă cu anteturi multilinii care acceptă și defilarea orizontală și coloane care sunt atât redimensionabile, cât și mobile, așa că am creat o clasă pentru a face acest lucru. Funcția care face posibil acest lucru este OBJTOCLIENT(). Această funcție returnează proprietatea Top, Left, Height sau Width a unui obiect în raport cu forma acestuia. Deoarece nici coloanele de grilă, nici anteturile de grilă nu au o proprietate Left, această poziție trebuie fie calculată prin adăugarea lățimii fiecărei coloane la un acumulator, ca în exemplul anterior, fie prin utilizarea funcției OBJTOCLIENT.

Rezultatul arată foarte tare și îi va impresiona pe toți prietenii tăi. Cu toate acestea, nu există un prânz gratuit. Prețul pentru această funcționalitate este o creștere mare a cantității de cod specific de instanță necesar pentru a o susține.

În loc de metoda ReplaceHeaders folosită în exemplul anterior, această clasă grilă are o metodă SetHeaders deoarece anteturile nu sunt de fapt înlocuite. Metoda SetHeaders creează etichete transparente care plutesc deasupra antetelor existente ale grilei cu o marjă suficientă pentru a permite utilizatorului final să facă clic pe antetul de mai jos pentru a muta sau redimensiona coloana.

Această clasă de grilă are două noi proprietăți personalizate:

• 	nHdrMargin·. specifică numărul de pixeli de lăsat între marginile etichetei și antetul grilei - valoarea implicită este de cinci pixeli

• 	nDreapta: stochează coordonatele x a poziției celei mai din dreapta în porțiunea vizibilă a grilei, astfel încât dacă avem coloane care nu sunt vizibile, nu facem vizibile etichetele antetelor acestora

De asemenea, am adăugat metoda RefreshHeaders pentru a repoziționa etichetele de fiecare dată când grila este derulată sau coloanele sunt mutate sau redimensionate. RefreshHeaders este apelat din metodele SetHeaders și Scrolled ale clasei grid. De asemenea, trebuie apelat din metodele Mutate și Redimensionare ale fiecărei coloane. Ultimele două cali trebuie plasate în fiecare instanță a acestei clase de grilă, o sarcină care poate fi făcută mai puțin obositoare prin crearea unui constructor pentru această clasă. Vom discuta despre un astfel de constructor mai târziu în capitolul despre instrumentele de productivitate pentru dezvoltatori.

Multi-Line Gr

Grilă derulabilă cu coloane redimensionabile și mobile

Grilă statică

	Situat în țara Nume complet de contact cu un alt antet foarte lung Număr de telefonNumăr de fax al clientului	
	ItaliaPaolo Accorti011-4988260011-4988261	
	Germen oricePeter Franken089-0877310089-0877451	
					
	VenezuelaManuel Pereira(2) 283-2951(2) 283-3397	
	SpaniaEduardo Saavedra(93) 203 4560(93) 203 4561	
	Spania José Pedro Freyre(95) 555 82 82		
	BraziiAndré Fonseca(1 1) 555-9482		

Director de vânzări titlul I

Note

Figura 6.3 Grilă cu mai multe linii

anteturi care suportă derulare orizontală și coloane mobile

Am inteles! Evenimentul derulat nu se declanșează atunci când tastele cursorului derulează grila

S-ar putea să ne chibească aici despre semantică, dar fișierul de ajutor Visual FoxPro spune că evenimentul Scrolled are loc într-un control sau formă grilă atunci când se face clic pe barele de defilare orizontale sau verticale sau se mișcă o casetă de defilare. Parametrul nDirection specifică modul în care utilizatorul a derulat prin conținutul unui control sau formular grilă. Apoi se listează următoarele valori posibile pentru nDirection·.

Tabelul 6.1 Valori posibile pentru parametrul nDirection în metoda derulată a grilei

Valoare 	Utilizatorul a derulat folosind...
0 	Tasta săgeată sus
1 	Tasta săgeată în jos
2 	Bară de defilare verticală în zona de deasupra casetei de defilare
3 	Bara de defilare verticală în zona de sub caseta de defilare
4 	Tasta săgeată la stânga
5 	Tasta săgeată la dreapta
6 	Bara de defilare orizontală în zona din stânga barei de defilare
7 	Bara de defilare orizontală în zona din dreapta barei de defilare

Credem că referirea la tastele SĂGEATĂ STÂNGA și SĂGEATĂ DREAPTA implică faptul că utilizarea acestor taste cursor pentru a derula grila pe orizontală declanșează metoda Scrolled și trece o valoare fie 4, fie 5 pentru nDirection. Aceasta nu. Chiar dacă grila se poate derula ca urmare a utilizării acestor taste, evenimentul său Scrolled nu se declanșează niciodată. Ceea ce însemna fișierul Ajutor atunci când vorbea despre tastele SĂGEATĂ STÂNGA și SĂGEATĂ DREAPTA a fost, de fapt, săgețile stânga și dreapta de pe bara de defilare orizontală.

Acesta este motivul pentru care metoda AfterRowColChange a clasei grdMLHeader conține următoarele linii de cod:

Grid::AfterRowColChange( nColIndex )

This.RefreshHeaders()

NODEFAULT

Cheia pentru funcționalitatea acestei clase de grilă poate fi găsită în metoda sa RefreshHeaders. Această metodă asigură că fiecare coloană din porțiunea vizibilă a grilei are eticheta corespunzătoare poziționată corect deasupra antetului său:

LOCAL lnCol, lcName, lnHdrLeft, lnHdrWidth

Thisform.LockScreen = .T.

Cu asta

*** Buclă prin fiecare coloană și asigurați-vă că eticheta este Stânga și Lățimea

*** proprietățile sunt setate corect

FOR lnCol = 1 TO .ColumnCount

lcName = "dHeader" + LTRIM( STR( lnCol ) )

WITH EVAL ("Acest.Parinte." + lcName)

lnHdrWidth = This.Columns[ lnCol ].Width - ( 2 * This.nHdrMargin )

.Width = IIF( lnHdrWidth > 0, lnHdrWidth, 0 )

lnHdrLeft = OBJTOCLIENT( This.Columns[ lnCol ].Controls[ 1 ], 2 )

*** Dacă suntem într-un container, află decalajul din formular

*** și ajustați valoarea din stânga

IF UPPER( This.Parent.BaseClass ) # 'FORM'

lnHdrLeft = lnHdrLeft - OBJTOCLIENT( This.Parent, 2 )

ENDIF

Dacă coloana nu se află în porțiunea vizibilă a grilei, primul apel la objtoclient returnează zero. Dacă grila este pe o pagină sau într-un alt container, lnHdrLeft va conține o valoare negativă după al doilea apel. Deci, dacă lnHdrLeft este mai mare decât zero, coloana curentă trebuie să fie în partea vizibilă a grilei:

*** Setați proprietățile din stânga și vizibile numai dacă această coloană este în

*** porțiune vizibilă a rețelei.

DACĂ lnHdrLeft > 0

.Left = lnHdrLeft + This.nHdrMargin

.Vizibil = .T.

*** asigurați-vă că lățimea nu depășește vizibilul

*** porțiune din grilă

DACĂ .Left + .Width > This.nRight

lnHdrWidth = This.nRight - .Left - ( 2 * This.nHdrMargin )

.Width = IIF( lnHdrWidth > 0, lnHdrWidth, 0 )

ENDIF

ALTE

.Vizibil = .F.

ENDIF

SE TERMINA CU

ENDFOR

SE TERMINA CU

Thisform.LockScreen = .F.

Clasa grid conține o altă metodă numită KeepHeadersVisible. Această metodă, după cum sugerează și numele, menține vizibile etichetele care plutesc deasupra antetelor grilei atunci când grila își pierde focalizarea. Ori de câte ori grila pierde focalizarea, anteturile cu mai multe linii dispar, deoarece anteturile grilei se deplasează în partea din față a z-ului.

comandați și ascundeți etichetele. Singura modalitate pe care am găsit-o de a împiedica acest lucru să se întâmple a fost prin invocarea metodei KeepHeadersVisible a grilei în metoda GotFocus a fiecărui obiect din formular, precum și în LostFocus al formularului. După cum am afirmat mai devreme, funcționalitatea sporită a acestei clase de rețea are un preț ridicat.

Folosind textul sfaturii instrument în locul antetelor cu mai multe linii

O soluție simplă pentru furnizarea de descrieri detaliate pentru anteturile coloanelor de grilă este furnizarea de sfaturi pentru instrumente pentru utilizator. Acest lucru poate fi realizat rapid, chiar dacă anteturile nu au o proprietate ToolTipText. Antetul poate folosi ToolTipText al grilei. O singură linie de cod, în metoda MouseMove a antetului, setează în mod corespunzător ToolTipText al grilei. Nu uitați să setați proprietatea ShowTips a formularului la true, deoarece este setată la false în mod implicit:

This.Parent.Parent.ToolTipText = 'Aceasta este o descriere lungă a antetului pentru coloană'

Desigur, există întotdeauna posibilitatea ca, odată ce utilizatorii dvs. finali văd aceste sfaturi ingenioase pentru instrumente, să clame să le aibă pe fiecare grilă din aplicație. În acest caz, probabil că veți dori să creați o clasă de antet personalizată care să conțină codul pentru a seta proprietatea ToolTipText a grilei în metoda MouseMove. Este ușor să definiți anteturi personalizate, dar nu se poate face vizual. Trebuie definit cu codul:

DEFINIȚI CLASA HdrBase AS Antet

FUNCȚIE MouseMove

LPARAMETERS nButton, nShift, nXCoord, nYCoord

Cu asta

.Parent.Parent.ToolTipText = .Tag

SE TERMINA CU

ENDFUNC

ENDDEFINE

Ultima cerință este un generator de grile personalizate care, printre altele, înlocuiește automat anteturile clasei de bază ale Visual FoxPro cu anteturile dvs. personalizate în momentul proiectării. După ce rulați generatorul, puteți plasa ToolTipText în proprietatea etichetei antetului personalizat. Pentru constructorul nostru de grile de rezistență industrială, consultați capitolul despre instrumentele de productivitate pentru dezvoltatori.
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Cum schimb ordinea de afișare a grilei? (Exemplu:

Ch06. VCX: : grdSetOrder)

Ca de obicei, răspunsul este „depinde”. Combo-Grid din ultimul capitol a folosit un meniu cu comenzi rapide pentru a realiza acest lucru. Aceeași funcționalitate poate fi obținută prin apelarea unei metode de grilă personalizată din Click din antetul. La fel ca exemplul anterior, dacă toate grilele dvs. au nevoie de aceasta este funcționalitate, ar trebui să vă îmbunătățiți clasa antet personalizată prin adăugarea unui cod la metoda sa Click.

„Setați ordinea rețelei după (

	CompanieContactCountryPhoneЖ
	Cactus Comidas para llevar Patricio SimpsonArgentina(1) 1 35-5555	
	Océano Atlántico LtdaYvonne MoneadaArgentina(1) 1 35-5333	
	1 ' oi 11. 11- i. г 1 J ь 		(Argentina|		
	Ernst HandelRoland MendelAustria7675-3425	
	Piccolo und mehrGeorg PippsAustria6562-9722	
	Maison DeweyCatherine DeweyBelgia(03) 201 24 67	
	Suprêmes delicesPascale CartrainBelgia(071) 23 67 22	
	Mineiro TradePedro AfonsoBrazii(1 1) 555-7647	
	Familia ArquibaldoAria CruzBrazii(1 1) 555-9857	
	Cafenele gourmetAndré FonsecaBrazii(1 1) 555-9482	
	Hanari CarnesMario PontesBrazii(21) 555-0091	
	Ce încântareBernardo BatistaBrazii(21) 555-4252	
	Regina CozinhaLúcia CarvalhoBrazii(1 1) 555-1 1 09	
	Ricardo AdoicadosJanete LimeiraBrazii(21) 555-3412	
	Hypermarket TraditionAnabeia DominguesBrazii(1 1) 555-21 67	
	Wellington ImportadoraPaula ParenteBrazii(1 4) 555-81 22	
	Piețe cu dolari de jos Elizabeth LincolnCanada(604) 555-4729▼

Figura 6.4 Elementele din grilă afișate în ordinea țării după ce ați făcut clic pe antet

Iată codul care merge în metoda Click din antet:

CU Aceasta.Părinte

.Parent.SetOrder( JUSTEXT( .ControlSource ) )

SE TERMINA CU

Există o presupunere ascunsă aici - că tu, la fel ca noi, urmați convenția de a acorda etichetelor index un singur câmp același nume cu câmpurile pe care se bazează. Metoda SetOrder a acestei clase de grilă, care este apelată din metoda Click din antet, depinde de faptul că aceasta este adevărată:

LPARAMETRI tcTag

*** Asigurați-vă că a fost transmis un nume de etichetă valid

DACĂ ! GOL (tcTag)

*** Asigurați-vă că avem fișierul de procedură încărcat, astfel încât să putem accesa

*** Funcția IsTagO

SETĂ PROCEDURA LA ADITIVUL Ch06

Cu asta

*** Asigurați-vă că este într-adevăr o etichetă pentru RecordSource a grilei

IF IsTag( tcTag, .RecordSource )

*** Continuă și stabilește ordinea pentru masă

SELECTARE ( .RecordSource )

SETARE COMANDA LA (tcTag)

.Seteaza focusul()

ENDIF

SE TERMINA CU

ENDIF
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Cum controlez cursorul? (Exemplu: NxtGridRow.scx)

Când utilizatorul apasă tasta Tab sau Enter pentru a naviga la următoarea celulă, comportamentul implicit al grilei este de a trece la următoarea coloană din același rând. Este posibil să solicitați ca grila dvs. să se comporte puțin diferit, mai ales dacă este folosită pentru a afișa calcule matematice. Deși o grilă nu este o foaie de calcul, utilizatorilor finali le poate fi mai ușor să învețe dacă apăsările sale de taste se comportă într-un mod familiar, poate ca Microsoft Excel. Este o sarcină simplă să construiești grile care navighează pe verticală, nu pe orizontală, atunci când utilizatorul apasă Tab sau Enter și pentru că o poți crea ca clasă, trebuie făcută o singură dată. Clasa de casete de text txtGrdNextRow furnizată împreună cu exemplul de cod pentru acest capitol oferă această funcționalitate. Are o singură metodă personalizată numită Move2NextRow și este apelată din metoda KeyPress a casetei de text atunci când este detectată tasta Enter sau Tab:

LOCAL InMaxRows

lnMaxRows = INT( ( .Height - .HeaderHeight - ;

IIF( INLIST( .ScrollBars, 1, 3 ), SYSMETRIC( 8 ), 0 ) ) / .RowHeight )

CU Acest.Părinte.Părinte

IF RelativeRow >= lnMaxRows

*** Asta înseamnă că ne aflăm pe ultimul rând din porțiunea vizibilă a grilei

*** Deci trebuie să derulăm grila în jos cu o linie

.DoScroll( 1 )

ENDIF

.ActivateCell( .RelativeRow + 1, .RelativeColumn )

SE TERMINA CU
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Cum afișez ultima pagină completă a unei grile? (Exemplu:

EndofGrid.scx)

În general, atunci când un formular care conține o grilă este instanțiat, prima înregistrare afișată în grilă este prima înregistrare din RecordSource. Evident, dacă aveți cod în metoda Init a grilei care mută indicatorul de înregistrare, acest lucru nu va fi adevărat. Dar există situații în care doriți să afișați o grilă complet populată în care ultima înregistrare disponibilă este afișată ca ultima linie a grilei. Acest lucru se poate face, dar nu este un exercițiu banal.

La început s-ar putea să vă gândiți „Oh, aceasta este o bucată de tort! Tot ce trebuie să fac este ceva de genul acesta:”

Cu asta

GO BOTTOM IN ( .RecordSource )

SKIP - <Număr de rânduri - 1> IN ( .RecordSource )

.Seteaza focusul()

SE TERMINA CU

Dar dacă testați de fapt această abordare, veți descoperi rapid că nu funcționează corect. Chiar dacă grila este poziționată pe înregistrarea corectă, această înregistrare se află în mijlocul paginii și trebuie să utilizați tasta PAGE DOWN pentru a vedea ultima înregistrare. Dacă aceasta este o cerință comună pentru grilele dvs., acest exemplu de cod din metoda Init a lui EndOfGrid.scx este generic și poate fi introdus cu ușurință într-o metodă personalizată a clasei dvs. de grilă:

LOCAL lnKey, lnMaxRows, lcKeyField

*** Asigurați-vă că fișierul de procedură este încărcat

SETĂ PROCEDURA LA ADITIVUL Ch06.prg

*** Afișează ultima pagină a grilei atunci când formularul se instanțează

IF DODEFAULT()

CU Thisform.GrdCustomer

*** Calculați numărul maxim de rânduri pe pagină de grilă

lnMaxRows = INT( ( .Height - .HeaderHeight - ;

IIF( INLIST( .ScrollBars, 1, 3 ), SYSMETRIC( 8 ), 0 ) ) / .RowHeight )

*** Obțineți numele câmpului cheie primară din RecordSource al grilei

*** GetPKFieldName este o funcție definită în fișierul de procedură pentru aceasta

*** Capitolul (Ch06.prg)

lcKeyField = GetPKFieldName( .RecordSource )

*** Obțineți cheia principală sau candidată a primei înregistrări care urmează să fie afișată

*** pe ultima pagină a grilei, deoarece scopul este să se umple grila

*** când se deschide formularul

GO BOTTOM IN ( .RecordSource )

SKIP -( lnMaxRows - 1 ) IN ( .RecordSource )

*** Salvați cheia principală sau candidată a acestei înregistrări, dacă are una

DACĂ ! EMPTY(lcKeyField)

lnKey = EVAL( .RecordSource + 	+ IcKeyField )

GO BOTTOM IN ( .RecordSource )

.Reîmprospătare ()

*** Derulați în sus o înregistrare până când ajungem la cea pe care vrem să facem în timp ce .T.

.ActivateCell( 1, 1 )

IF EVAL( .RecordSource + '.' + lcKeyField ) = lnKey

IEȘIRE

ALTE

.DoScroll( 0 )

ENDIF

ENDDO

ENDIF

SE TERMINA CU

ENDIF
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Cum folosesc o grilă pentru a selecta unul sau mai multe rânduri? (Exemplu:

SelGrid.scx)

O grilă cu selecție multiplă este soluția perfectă atunci când trebuie să prezentați utilizatorului o listă mare de articole din care pot fi făcute selecții multiple. Singura cerință este ca tabelul folosit ca RecordSource al grilei trebuie să aibă un câmp logic care poate fi setat la adevărat atunci când acel rând este selectat. Dacă tabelul de bază nu are un câmp logic, este o chestiune simplă să furnizați unul fie prin crearea unei vizualizări locale din tabel, fie folosind-o pentru a construi un cursor actualizabil. Consultați Capitolul 9 pentru detalii despre cum să construiți o sursă de înregistrare pentru grila care conține acest indicator de selecție.

Figura 6.5 Grilă de selectare multiplă folosind casetele de selectare a stilului grafic

Configurarea acestei grile este atât de ușoară încât nici măcar nu necesită o clasă de grilă personalizată. În exemplul de mai sus, am aruncat doar una dintre grilele noastre de clasă de bază (ChO6::grdBase) în formularul nostru și am adăugat trei linii de cod la metoda sa SetGrid:

DODEFAULT()

*** Configurați pentru evidențierea AT .T, rânduri selectate

This.SetAll( 'DynamicBackColor', ;

4IF( ISelectat, RGB( 0, 0, 128 ), RGB( 0, 0, 0 ) )', „COLUMN” )

This.SetAll( 'DynamicBackColor', ;

4IF( ISelectat, RGB( 0,255,255 ), RGB( 255, 255, 255 ) )', „COLOANĂ” )

Tot ce rămâne este să adăugați o casetă de selectare a stilului grafic la prima coloană a grilei și să puneți două linii de cod în metoda Click:

DODEFAULT()

TASTATURA „{DNARROW}”

Acest cod mută cursorul pe următorul rând din grilă. Mai important, evidențiază corect rândul curent în funcție de dacă utilizatorul l-a selectat sau nu. Acest lucru se datorează faptului că metoda setall care este utilizată pentru a evidenția rândurile selectate nu modifică aspectul grilei până când nu este emis un Grid.SetFocus() sau un Grid.Refresh(). Reîmprospătarea constantă a rețelei va degrada performanța și trecerea la rândul următor realizează același obiectiv și face grila mai convenabilă pentru utilizatorul final.

Cum îmi ofer grila cu selecție multiplă capacitatea de căutare incrementală? (Exemplu: Ch06.VCX::txtSearchGrid)

Din punct de vedere tehnic, acest lucru se realizează prin plasarea unei casete de text cu capacitate de căutare incrementală într-una sau mai multe coloane ale grilei. Evident, orice coloană cu această funcționalitate trebuie, prin definiție, să fie doar în citire. În caz contrar, utilizatorul ar schimba în mod constant datele în timp ce căuta!

Cheia pentru crearea unei casete de text de căutare incrementală pentru utilizare într-o grilă este adăugarea proprietății cSearchString pentru a păstra șirul de căutare curent. Acest lucru implică faptul că toate apăsările de taste sunt interceptate și transmise unui handler personalizat de apăsare a tastei care fie folosește cheia pentru a construi șirul de căutare, fie o trece prin metoda KeyPress a controlului pentru a fi gestionată implicit. (Tastele de navigare precum TAB, ENTER și DNARROW pot fi gestionate deoarece Visual FoxPro gestionează în mod normal astfel de taste.)

Managerul de apăsare a tastei necesită, de asemenea, unele mijloace de implementare a unei condiții de „time out” pentru a reseta șirul de căutare. Proprietatea personalizată, nTimeOut, deține numărul maxim de secunde care poate trece între apăsarea tastei înainte ca controlul să expire și proprietatea sa cSearchString să fie resetata. De asemenea, am adăugat proprietatea tLastPress pentru a menține ultima dată când a fost apăsată o tastă în format DateTime. Aceste două proprietăți sunt utilizate de metoda noastră personalizată Handlekey pentru a îndeplini această sarcină.

Am oferit casetei de text o metodă SetTag care include cod pentru a optimiza căutarea utilizând etichete index, dacă acestea sunt disponibile. Se rulează când controlul este instanțiat. Presupunem, ca întotdeauna, că toate etichetele de index de câmp au același nume ca și câmpul pe care se bazează. Acesta este modul în care metoda SetTag inițializează proprietatea personalizată cTag a casetei de text:

CU Aceasta.Părinte

*** Dacă coloana este legată, vezi dacă există o etichetă în RecordSource a grilei

*** care are același nume cu câmpul la care este legată coloana

DACĂ ! EMPTY( .ControlSource )

*** Asigurați-vă că fișierul de procedură este încărcat

SETĂ PROCEDURA LA CH06.Prg ADITIV

IF IsTag( JUSTEXT( .ControlSource ), .Parent.RecordSource )

This.cTag = JUSTEXT( .ControlSource )

ENDIF

ENDIF

SE TERMINA CU

Cea mai mare parte a muncii este efectuată în metoda HandleKey a controlului, care este apelată din metoda KeyPress. Dacă apăsarea tastei este gestionată cu succes prin această metodă, .t. este returnat la metoda KeyPress, care apoi emite un NODEFAULT. Dacă apăsarea tastei nu este gestionată prin această metodă, .f. este returnat și apare comportamentul implicit Visual FoxPro KeyPress:

LPARAMETERS tnKeyCode

*** Mai întâi verificați dacă avem o cheie pe care o putem manipula

*** Un caracter „printabil”, backspace sau <DEL> sunt candidați buni

DACĂ ÎNTRE(tnKeyCode, 32, 128) SAU tnKeyCode = 7

Cu asta

*** Mai întâi verificați dacă am expirat

*** și resetați șirul de căutare dacă avem

IF DATETIME() - .tLastPress > .nTimeOut

.cSearchString = ''

ENDIF

*** Așa că acum mânuiește cheia

FACE CAZ

CAZ tnKeyCode = 7

*** Dacă a fost apăsată tasta de ștergere, resetați șirul de căutare

*** și etapa de ieșire la stânga

.cSearchString = ''

RETURNARE .T.

CASE tnKeyCode = 127

*** Backspace: eliminați ultimul caracter din șirul Căutare

IF LEN( .cSearchString ) . 1

.cSearchString = LEFT( .cSearchString, LEN( .cSearchString ) - 1 )

ALTE

.cSearchString = ''

RETURNARE .T.

ENDIF

IN CAZ CONTRAR

*** Un personaj imprimabil cu varietate de grădină

*** adăugați-l la șirul de căutare

.cSearchString = .cSearchString + CHR( tnKeyCode )

ENDCASE

*** Căutați cea mai apropiată potrivire din sursa de înregistrare a grilei

.Căutare()

*** Actualizați valoarea pentru temporizatorul de interval KeyPress

.tLastPress = DATETIME()

SE TERMINA CU

ALTE

*** Nu o cheie pe care o putem manipula. Lăsați VFP să se ocupe de asta în mod implicit

This.cSearchString = ''

RETURNARE .F.

ENDIF

Metoda de căutare încearcă să găsească cea mai apropiată potrivire de șirul de căutare în RecordSource al grilei. Dacă nu se găsește nicio potrivire, restabilește indicatorul de înregistrare la poziția sa curentă:

LOCAL InSelect, lnCurRec, lcAlias

*** Salvați zona de lucru curentă

lnSelect = SELECT ()

*** Obțineți RecordSource al grilei

lcAlias = This.Parent.Parent.RecordSource

Thisform.LockScreen = .T.

*** Căutați potrivirea de închidere a șirului de căutare

Cu asta

*** Salvați înregistrarea curentă

lnCurRec = RECNO( lcAlias )

DACĂ ! GOL ( .cTag )

*** Folosiți o etichetă index dacă există una

IF SEEK( UPPER( .cSearchString ), lcAlias, .cTag )

*** Nu face nimic... am găsit o înregistrare

ALTE

*** Restaurați indicatorul de înregistrare

GO lnCurRec IN (lcAlias)

ENDIF

ALTE

*** Fără etichetă... trebuie să folosești LOCATE

SELECTARE (lcAlias)

LOCATE FOR UPPER( EVAL( JUSTEXT( .Parent.ControlSource ) ) ) = ;

SUS ( .cSearchString )

DACĂ ! GĂSITE()

GO lnCurRec

ENDIF

SELECTARE ( lnSelect )

ENDIF

SE TERMINA CU

Thisform.LockScreen = .F.
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Cum folosesc DynamicCurrentControl? (Exemplu: DCCGrid.scx)

Utilizați această proprietate pentru a alege care dintre mai multe controale posibile dintr-o singură coloană grilă este afișată în orice moment. Ca și alte proprietăți dinamice, cum ar fi DynamicBackColor și DynamicForeColor, puteți specifica o condiție care este evaluată de fiecare dată când grila este reîmprospătată.

Figura 6.6 Utilizarea

DynamicCurrentControl pentru a afișa diferite controale

Acest exemplu folosește DynamicCurrentControl pentru a activa selectiv caseta de selectare a stilului grafic din prima coloană a grilei. Acesta este singurul mod de a realiza acest lucru, deoarece utilizarea metodei SetAll a coloanei pentru a activa selectiv casetele de selectare nu funcționează. Acest cod, în metoda SetGrid a grilei, face ca orice casetă de selectare din coloană să fie dezactivată atunci când se face un atempi pentru a se concentra asupra acesteia:

This.collSelected.setall( „Activat”, ;

IIF( UPPER( ALLTRIM ( lv_Customer.Title ) ) = 'PROPRIETAR' , .F., .T. ), ; "CASETA DE BIFAT" )

Pentru a profita de DynamicCurrentControl al coloanei, asigurați-vă că coloana conține toate controalele care urmează să fie afișate. Pentru ca aceasta să funcționeze, proprietatea Sparse a coloanei trebuie, de asemenea, setată la false. Prima coloană din grila de mai sus conține două controale. Prima este o casetă de selectare a stilului grafic al clasei de bază. A doua este o clasă personalizată de „casetă de validare dezactivată”. După adăugarea controalelor la coloană, singura altă cerință este această linie de cod în metoda SetGrid a rețelei:

This.collSelected.DynamicCurrentControl = ;

„IIF( UPPER( ALLTRIM( lv_Customer.Title ) ) = „PROPRIETAR”, ;

„chkDisabled”, „chkSelected” )”

Când rulați exemplul, veți vedea că nu puteți selecta niciun rând în care titlul persoanei de contact este „Proprietar”.
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Cum modific conținutul unei grile? (Exemplu: FilterGrid.scx)

În zilele noastre, este rar ca o aplicație să prezinte utilizatorului toate înregistrările conținute într-un tabel. De cele mai multe ori, un subset al datelor disponibile este selectat pe baza unor criterii. Metoda tradițională în FoxPro a fost utilizarea unui fdter. Cu toate acestea, este o idee proastă ca datele care sunt afișate în grilă, deoarece grilele nu pot utiliza optimizarea Rushmore. De fapt, setarea unui filtru pe RecordSource a grilei dvs. este cea mai rapidă modalitate pe care o cunoaștem de a vă aduce aplicația în genunchi. Mai mult, de îndată ce începeți să lucrați cu date dintr-o bază de date backend, setarea unui filtru nici măcar nu este o opțiune. Trebuie să selectați un subset de date fie într-o vizualizare, fie într-un cursor actualizabil.

Figura 6.7 Grile filtrate folosind cursorul actualizabil și vizualizarea parametrizată

Codul care populează RecordSources pentru grilele din imaginea de mai sus poate fi găsit în metodele respective de resetare. Metoda Reset este o metodă șablon care a fost adăugată la grila clasei noastre de bază în acest scop. Deoarece conținutul grilei de detalii depinde de ce rând este ActiveRow din grila de categorii, iar conținutul grilei de categorii depinde de ceea ce este selectat în caseta combinată, o metodă ResetGrids a fost adăugată în formular. Metoda este apelată din metoda Valid din caseta combinată și doar calizează metoda Reset a fiecărei grile.

RecordSource a grilei de categorii este un cursor actualizabil. Acest cursor, csrCategory, este definit în metoda Load a formularului folosind comanda CREATE CURSOR. Cursorul este populat în metoda Reset a grilei prin zapping csrCategory, selectând înregistrările corespunzătoare într-un cursor temporar și apoi adăugând înregistrările din cursorul temporar în csrCategory. Resetarea este o metodă personalizată pe care am adăugat-o la clasa noastră grid pentru a popula sau repopula în mod constant toate grilele folosind o metodă comună. Iată codul din metoda de resetare a grilei de categorii:

SELECTAȚI CsrCategory

ZAP

SELECTAȚI * DIN Categorii ;

WHERE Categories.Cat_No = This.Parent.cboSections.Value ;

INTO CURSOR Temp NOFILTER

SELECTAȚI CsrCategory

APPEND FROM DBF('Temp')

UTILIZARE ÎN Temp

Mergeți sus în categoria csr

Aceasta.nRecNo = 1

Acest. Reîmprospăta()

Există câteva motive pentru a face acest lucru. În primul rând, putem seta grila de categorii vizual în designerul de formulare, deoarece RecordSource există înainte de instanțiere. Mai important este faptul că unei grile nu-i place să i se scoată RecordSource de sub ea. Dacă RecordSource a grilei ar fi actualizat selectând direct în ea, ar apărea ca o pată gri goală pe ecran. Acest lucru se datorează faptului că selectarea închide cursorul și lasă efectiv grila în aer, ca să spunem așa. ZAPing-o, pe de altă parte, nu.

O modalitate de a evita ca grila să se transforme într-un blob gri gol este să setați RecordSource la un șir gol înainte de a rula selectarea și apoi a-l reseta ulterior. Deși acest lucru va funcționa în cele mai simple cazuri, nu este o soluție pe care o recomandăm. Deși vă va împiedica grila să-și piardă mințile, coloanele grilei își pierd în continuare sursele de control și orice comenzi încorporate. Deci, acest lucru funcționează dacă grila dvs. folosește anteturi de clasă de bază, casete de text ale clasei de bază și afișează câmpurile din cursor în exact aceeași ordine în care sunt SELECTATE. În caz contrar, trebuie să scrieți mult mai mult cod pentru a restaura toate lucrurile care se pierd atunci când grila este reinițializată.

O altă modalitate de a afișa un subset filtrat într-o grilă este să utilizați o vizualizare parametrizată ca sursă de înregistrare. Așa se realizează în grila de detalii. Metoda de resetare folosește următorul cod pentru a schimba ceea ce este afișat. Această metodă este apelată din metoda AfterRowColChange a grilei de categorii pentru a le menține sincronizate:

LOCAL vp_Cat_Key

vp_Cat_Key = csrCategory.Cat_Key

REQUERY( 'lv_Details' )

MERGE SUS ÎN lv_Detalii

Aceasta.nRecNo = 1

This.Refresh()

Vederea la care este legată se află în mediul de date al formularului și are proprietatea NoDataOnLoad setată la true. Facem acest lucru deoarece nu știm ce detalii vor fi afișate inițial în grilă și nu dorim ca Visual FoxPro să solicite utilizatorului un parametru de vizualizare atunci când se deschide formularul. Pentru informații mai detaliate despre vederile parametrizate, consultați Capitolul 9.
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Deci, cum rămâne cu grilele de introducere a datelor? (Exemplu: Ch06.VCX::grdDataEntry și DataEntryGrid.scx)

Deci ce zici de ei? Cu siguranță nu sunt pentru timizi. Dacă încerci să-i forțezi să facă lucruri pe care nu le descurcă bine, vor fi cel mai rău coșmar al tău! De exemplu, în unele aplicații de contabilitate este logic să se furnizeze o grilă pentru introducerea datelor. În acest caz, utilizatorul final va fi probabil cel mai confortabil folosind acest tip de interfață, deoarece majoritatea contabililor par să iubească foile de calcul. Am putut folosi grile de introducere a datelor fără a ne smulge părul în acest proces. Acest lucru se datorează faptului că ne-am luat timp să înțelegem cum funcționează grilele și am găsit câteva tehnici care funcționează în mod consecvent și fiabil. Le împărtășim cu dvs., astfel încât experiența dvs. cu grilele de introducere a datelor poate fi mai puțin dureroasă decât pare a fi pentru majoritatea.

Un cuvânt de precauție este necesar aici. Dacă examinați codul din formularul nostru de exemplu de grilă de introducere a datelor, veți fi surprins de numărul de soluții (cludges, dacă doriți să fiți clar) necesare pentru a implementa funcționalitatea în cadrul rețelei în sine. Am lăsat-o în eșantion pentru a vă arăta că se poate. Cu toate acestea, plătiți un preț mare dacă încercați să deveniți prea drăguț cu grilele de introducere a datelor. Cu cât încercați să includeți mai multe funcționalități în grilă, cu atât veți avea mai multe probleme din cauza interacțiunii complexe dintre evenimentele din grilă și cele ale controalelor conținute. De exemplu, dacă aveți cod în metoda LostFocus a unei casete de text dintr-o coloană grilă care determină declanșarea evenimentului BeforeRowColChange al grilei și există cod în acea metodă care nu ar trebui să se execute în această situație, trebuie să utilizați un indicator pentru a determina când ar trebui executat. Acest lucru poate deveni urât foarte repede. Păstrați-o simplă și vă veți menține durerile de cap la minimum.

Cum adaug înregistrări noi la grila mea?

Proprietatea AllowAddNew a fost adăugată la grilă în Visual FoxPro versiunea 5.0. Când această proprietate este setată la adevărat, o înregistrare nouă este adăugată automat la grilă dacă utilizatorul apasă tasta SĂGĂȚĂ JOS în timp ce cursorul este poziționat pe ultimul rând al grilei. Setarea acestei proprietăți la true pentru a adăuga înregistrări noi la grilă nu este ideală, deoarece nu aveți control asupra când și cum sunt adăugate înregistrările.

Există câteva moduri diferite de a adăuga înregistrări noi la grilă. Preferăm să folosim un buton nou lângă grilă. Un buton de comandă afișat lângă grilă cu legenda „Nou <Ceva sau altceva>” nu este ambiguu. Chiar și un utilizator final începător își poate da seama că făcând clic pe un buton „Nou” adaugă o nouă înregistrare la grilă (deși ne-am întrebat dacă cineva ar crede în mod eronat că înseamnă „Grilă nouă”). De asemenea, puteți simula ce face Visual FoxPro când AllowAddNew este setat la true. De exemplu, verificați dacă utilizatorul a apăsat tasta Enter, Tab sau săgeată în jos din ultima coloană a grilei și adăugați o înregistrare dacă cursorul este poziționat pe ultimul rând al grilei.

Majoritatea utilizatorilor par să preferă să adauge noi înregistrări în partea de jos a grilei. Acesta este comportamentul implicit atunci când RecordSource al grilei este afișat în ordine naturală. Cu toate acestea, dacă RecordSource al grilei are un

controlând eticheta index în vigoare, înregistrarea nou adăugată apare în partea de sus a grilei. Acesta este motivul pentru care metoda noastră personalizată AddNewRecord din clasa grilă de introducere a datelor salvează ordinea curentă și dezactivează indecșii înainte de a adăuga noua înregistrare. După ce noua înregistrare este focalizată, ordinea inițială este restabilită, lăsând înregistrarea nou atașată ca ultima din grilă:

LOCAL lcOrder, loColumn

Cu asta

*** Mai întâi verificați pentru a vedea dacă avem o ordine de index stabilită pe tabel

*** pentru că dorim să adăugăm noua înregistrare în partea de jos a grilei

*** și nu în ordinea indexului

lcOrder = ORDER( .RecordSource )

Thisform.LockScreen = .T.

SELECTARE ( .RecordSource )

SETĂ COMANDA PENTRU

ANEXAȚI BLACK ÎN ( .RecordSource )

*** Aflați care coloană este prima coloană

PENTRU FIECARE loColumn IN .Columns

DACĂ loColumn.ColumnOrder = 1

loColumn.SetFocus()

IEȘIRE

ENDIF

ENDFOR

*** Resetați comanda anterioară

DACĂ ! EMPTY(lcOrder)

SETĂ COMANDA LA ( lcOrder ) IN ( .RecordSource )

ENDIF

.RefreshControls()

ThisForm.LockScreen = .F.

SE TERMINA CU

Această metodă poate fi apelată din metoda personalizată OnClick a unui buton de comandă sau poate fi apelată condiționat din metoda KeyPress a unui control conținut într-o coloană grilă. Acest cod din metoda LostFocus a casetei de text din ultima coloană a grilei poate fi folosit pentru a adăuga automat o nouă înregistrare în grilă atunci când cursorul este poziționat pe ultimul său rând. Luați notă de codul care setează în mod explicit focalizarea pe un obiect diferit din formular. Încercarea de a adăuga o înregistrare la RecordSource al grilei când grila este ActiveControl, face ca Visual FoxPro să genereze eroarea 109 ("Înregistrare utilizată de către altul").

*** Verificați dacă a fost apăsat TAB, ENTER sau DNARROW

DACĂ INLIST( LASTKEY(), 9, 13, 24 )

CU Acest.Părinte.Părinte

*** Verificați EOF, astfel încât dacă suntem la sfârșitul fișierului, putem adăuga o nouă înregistrare dacă

*** TAB, ENTER., SAU Down Arrow a fost lovit

SKIP IN ( .RecordSource )

DACĂ ! EOF( .RecordSource )

SKIP -1 IN ( .RecordSource )

ALTE

*** Setați focalizarea în altă parte pentru a evita eroarea 109 - „Înregistrare în uz de către altcineva”

*** Putem la fel de bine să focalizăm temporar pagina

*** De asemenea, dacă NU punem focalizarea în altă parte, chiar dacă AddNewRecord

Metoda *** adaugă într-adevăr o nouă înregistrare, cursorul se deplasează la prima

*** coloana ultimului rând și NU se mută la prima coloană a

*** înregistrare nou adăugată. De asemenea, trebuie să setăm indicatorul lAdding astfel încât validarea

*** nu apare pe înregistrare înainte de a fi afișat în grilă

.lAdăugarea = .T.

.Parent.SetFocus()

. Adăugați înregistrare nouă ( )

.lAdăugarea = .F.

NODEFAULT

ENDIF

SE TERMINA CU

ENDIF

Odată ce noua înregistrare a fost adăugată și utilizatorul începe editarea, ce ar trebui să se întâmple? Dacă grila este afișată în ordine indexată, înregistrarea nou adăugată ar trebui să se mute în poziția corectă de îndată ce câmpul relevant este completat. Pentru a afișa înregistrarea în poziția corectă, puteți doar să mutați indicatorul de înregistrare, să o mutați înapoi și să reîmprospătați grila. Acest lucru funcționează, dar poate avea unele efecte secundare vizuale neplăcute. O soluție mai bună poate fi găsită în clasa de casete text txtOrderGrid. Poate fi folosit în coloanele de grilă care sunt legate de câmpul cheie al etichetei index de control a grilei pentru a schimba ordinea de afișare a grilei de îndată ce caseta de text pierde focalizarea:

LOCAL lnrecno

*** Dacă RecordSource al grilei are ordinea setată la eticheta index

*** pe acest câmp, dorim să ne asigurăm că de îndată ce îi modificăm conținutul,

*** ordinea de afișare a grilei reflectă această modificare.

*** În primul rând, verificați dacă am modificat acest câmp

IF INLIST( GETFLDSTATE( JUSTEXT( This.ControlSource ), ;

This.Parent.Parent.RecordSource ), 2, 4 )

Thisform.LockScreen = .T.

CU Acest.Părinte.Părinte

lnRecno = RECNO( .RecordSource )

*** Derulați în sus o pagină

GO TOP IN ( .RecordSource )

.DoScroll(2)

*** Derulați înapoi în jos o pagină

GO BOTTOM IN ( .RecordSource )

.DoScroll(3)

*** În sfârșit, reveniți la înregistrarea inițială

GO lnRecno IN ( .RecordSource )

SE TERMINA CU

Thisform.LockScreen = .f.

ENDIF

Cum mă ocup de validarea la nivel de rând în grila mea de introducere a datelor?

Ca de obicei, există mai multe moduri de a gestiona validarea la nivel de înregistrare. Dacă grila de introducere a datelor este legată de un tabel Visual FoxPro, o regulă poate fi definită în DBC (a se vedea capitolul 7 pentru mai multe informații despre regulile tabelului). Dacă RecordSource al grilei este o vizualizare, dbsetpropo poate fi folosit pentru a defini o regulă la nivel de rând. De fiecare dată când utilizatorul încearcă să se mute pe un alt rând din grilă, regula se va declanșa și va valida rândul curent. Pare destul de simplu, nu-i așa? Ei bine, nu tocmai. Regulile de tabel nu oferă validare completă la nivel de rând în toate situațiile și codul este încă necesar pentru a se asigura că această validare este efectuată acolo unde este necesar. De exemplu, utilizatorul poate ieși din grilă și poate închide formularul, lăsând o înregistrare nevalidă în RecordSource a grilei. În acest caz, regula tabelului nu se declanșează deoarece indicatorul de înregistrare nu s-a mutat. Și ce se întâmplă dacă decideți să utilizați un cursor actualizabil ca sursă de înregistrare pentru grila dvs.? Tehnic vorbind, atunci științific nu ai noroc.

Clasa noastră grilă de introducere a datelor conține cod generic pentru a gestiona validarea la nivel de înregistrare. Validarea reală este gestionată în metoda șablon numită ValidateCurrentRow pe care am adăugat-o la clasa noastră de grilă de introducere a datelor tocmai în acest scop. Codul din această metodă este specific unei instanțe și poate fi folosit pentru a valida rândul curent din RecordSource al grilei, chiar dacă este un cursor actualizabil. Dacă ați ales să definiți o regulă la nivel de înregistrare pentru tabelul sau vizualizarea dvs., metoda poate fi lăsată goală fără probleme. Rezultatul este o clasă de grilă generică de introducere a datelor care poate fi utilizată cu orice tip de RecordSource și poate efectua validarea la nivel de rând atunci când este necesar. Singura cerință este ca RecordSource al grilei să fie în buffer de tabel.

Metodologia de bază folosită aici este salvarea numărului de înregistrare curent în metoda BeforeRowColChange a grilei. Apoi, în metoda sa AfterRowColChange, această valoare salvată este comparată cu numărul de înregistrare curent. Dacă sunt diferite, utilizatorul s-a mutat pe un rând diferit din grilă. În acest caz, indicatorul de înregistrare este mutat înapoi la înregistrarea pe care utilizatorul tocmai a lăsat-o și conținutul acelei înregistrări este validat. Dacă înregistrarea este validă, este permisă trecerea intenționată către noua înregistrare.

Singura problemă este că mutarea indicatorului de înregistrare în mod programatic în RecordSource al grilei determină declanșarea evenimentului său BeforeRowColChange. De aceea verificăm dacă ne aflăm în mijlocul procesului de validare în această metodă:

Cu asta

DACĂ .IValidatingRow

NODEFAULT

ALTE

*** Salvați numărul de înregistrare curent în proprietatea grilei

.nRec2Validate = RECNO(.RecordSource)

*** Acest cod gestionează evidențierea rândului curent

DACA !.lAbout2LeaveGrid

.nRecNo = 0

ENDIF

ENDIF

SE TERMINA CU

Proprietatea lValidatingRow a grilei este setată la true în metoda sa AfterRowColChange când începe procesul de validare. Iată codul care inițiază procesul și se ocupă de mișcarea dintre rândurile de grilă:

LOCAL lnRec2GoTo

Cu asta

*** Dacă nu există nicio înregistrare de validat, părăsiți etapa din stânga

DACĂ .nRec2Validate = 0

ÎNTOARCERE

ENDIF

*** Salvați numărul de înregistrare curent în cazul în care am schimbat rândurile

lnRec2GoTo = RECNO( .Recordsource )

*** Verificați dacă rândul s-a schimbat

DACĂ .nRec2Validate # lnRec2GoTo

*** Validăm rândul pe care încercăm să-l părăsim... setați steagul

.lValidatingRow = .T.

*** Reveniți la înregistrarea pe care tocmai l-am lăsat

GOTO .nRec2Validate IN ( .Recordsource )

*** Dacă se verifică, permiteți utilizatorului să treacă la noul rând

IF .ValidateCurrentRow()

GOTO lnRec2GoTo IN ( .RecordSource )

.RefreshControls()

ENDIF

*** S-a terminat cu validarea... reset flag

.lValidatingRow = .F.

ENDIF

SE TERMINA CU

În cele din urmă, adăugăm un mic cod la metoda Valid a clasei de grilă de introducere a datelor. Acest lucru împiedică utilizatorul să părăsească grila dacă rândul curent conține informații nevalide:

*** Asigurați-vă că rândul curent rămâne evidențiat atunci când focalizarea părăsește grila

Aceasta.LAbout2LeaveGrid = .T.

*** Asigurați-vă că rândul curent al grilei este valid înainte de a părăsi grila

DACĂ ! This.ValidateCurrentRow()

RETURNARE 0

ENDIF

Codul din metoda ValidateCurrentRow a grilei este specific unei instanțe. Deoarece este apelat ori de câte ori utilizatorul încearcă să se mute de pe rândul curent, modificările acestei înregistrări pot fi comise dacă trec validarea. Cu toate acestea, există o mică problemă când această metodă este apelată din metoda Valid a Gridului. Deoarece Valid-ul grilei se declanșează înainte de Valid-ul CurrentControl din grilă, această metodă trebuie, de asemenea, să se asigure că sursa de control a celulei grilei active a fost actualizată de la valoarea sa înainte de a încerca să valideze înregistrarea curentă. Încercarea de a explica acest raționament este dificilă, așa că vom încerca să clarificăm acest lucru folosind un exemplu.

Să presupunem că o înregistrare nouă a fost adăugată la grilă și informațiile sunt introduse. După introducerea numărului de telefon, utilizatorul dă clic pe butonul de închidere al formularului pentru a ieși. În acest caz, Valid-ul grilei se declanșează, apelând metoda ValidateCurrentRow. În acest moment, evenimentul Valid al casetei de text, legat de câmpul numărului de telefon, nu s-a declanșat încă. Prin urmare, caseta de text din grilă conține valoarea care tocmai a fost introdusă de utilizator, dar sursa de control (adică numărul de telefon din memoria tampon de înregistrare) este încă goală. Încercarea de a rula validarea la nivel de înregistrare în acest moment, înainte de a forța declanșarea casetei de text Valid, ar produce rezultate eronate. Validarea s-ar afișa corect

un mesaj care informează utilizatorul că câmpul pentru numărul de telefon nu poate fi gol, chiar dacă utilizatorul ar putea vedea un număr de telefon pe ecran!

Pentru a rezolva această problemă, am adăugat cod la metoda ValidateCurrentRow, forțând metoda Valid a celulei active a grilei să se declanșeze înainte de a încerca să validăm rândul curent. Următorul cod, din metoda ValidateCurrentRow a formularului exemplu, ilustrează tehnica:

LOCAL lnRelativeColumn

*** Mod ascuns de a actualiza sursa de date din buffer

*** În caz contrar, dacă acesta este apelat din grilă este valabil atunci când utilizatorul

*** încearcă să închidă formularul făcând clic pe butonul de închidere sau încearcă

*** pentru a activa pagina 2, mesajul de eroare se va declanșa chiar dacă doar avem

*** a adăugat un număr de telefon, dar încă nu a fost eliminat de pe telefon

Cu asta

lnRelativeColumn = .RelativeColumn

Thisform.LockScreen = .T.

DACĂ lnRelativeColumn = 1

.ActivateCell( .RelativeRow, 2 )

ALTE

.ActivateCell( .RelativeRow, 1 )

ENDIF

.ActivateCell( .RelativeRow, lnRelativeColumn )

Thisform.LockScreen = .F.

SELECTARE ( .RecordSource )

*** Compania, contactul și telefonul sunt câmpuri obligatorii

DACĂ EMPTY ( Companie ) SAU EMPTY ( Contact ) SAU EMPTY ( Telefon )

MESSAGEBOX( 'Compania, contactul și telefonul sunt necesare.', 48, ;

„Vă rugăm să vă remediați intrarea” )

RETURNARE .F.

ALTE

*** Totul este valid... mergeți mai departe și actualizați sursa de înregistrare a grilei

DACĂ !TABLEUPDATE( 0, .F., .RecordSource )

MESSAGEBOX( 'Problemă la actualizarea tabelului clienți', 64, 'Ne pare rău' )

ENDIF

ENDIF

SE TERMINA CU

Cum șterg înregistrările din grila mea de introducere a datelor?

Proprietatea DeleteMark a unei grile determină dacă indicatorul de ștergere este afișat pentru fiecare rând din grilă. Când este afișat, utilizatorul poate comuta starea ștearsă a unei înregistrări făcând clic pe DeleteMark. Cu toate acestea, permiterea utilizatorilor să șteargă înregistrările în acest mod nu este o idee bună, deoarece nu permite controlul asupra momentului și modului în care înregistrările sunt șterse. O soluție mai bună este prezentarea utilizatorului cu un buton de comandă care oferă această funcționalitate. Deoarece nu există un răspuns „corect”, am prezentat ambele abordări în exemplul de cod.

După cum sa menționat mai devreme, volumul codului și durerile de cap sunt direct proporționale cu cantitatea de funcționalitate pe care încercați să o implementați în grila de introducere a datelor. Acest lucru este valabil mai ales atunci când permiteți utilizatorilor

ștergeți și recalibrați înregistrările din grilă făcând clic pe DeleteMark. Acesta este motivul pentru care metoda DeleteRecord pe care am adăugat-o la clasa grdDataEntry presupune că este apelată de la un obiect din afara grilei.

Cea mai mare problemă la ștergerea înregistrărilor din grilă este ca înregistrarea să dispară din grilă. Această problemă este rezolvată destul de ușor prin mutarea indicatorului de înregistrare în grile RecordSource și reîmprospătarea grilei, fie prin apelarea explicită a metodei Refresh, fie prin setarea focusului pe aceasta. Evident, pentru ca acest lucru să funcționeze, trebuie să fie activat DELETED. Amintiți-vă, set deleted este una dintr-o lungă listă de setări care se limitează la sesiunea curentă de date! Acest cod din metoda DeleteRecord a clasei noastre de grile de introducere a datelor ilustrează cum să faceți înregistrarea ștearsă să dispară din grilă după ce este ștearsă:

LOCAI loColumn

*** Asigurați-vă că utilizatorul CURATĂ dorește să ștergă înregistrarea curentă

*** Afișează butoanele Da și Nu, pictograma semnului exclamației

*** și faceți din al doilea buton (NU) butonul implicit

IF MESSAGEBOX( 'Ești ABSOLUT POZITIV Fără îndoială SIGUR' + ;

CHR(13) + „Doriți să ștergeți această înregistrare?”, 4+48+256, ;

— Ești CHIAR sigur? ) = 6

Cu asta

*** Dacă suntem în proces de adăugare a unei înregistrări și decidem să o ștergem

*** Doar inversează-l

IF '3' $ GETFLDSTATE( -1, .RecordSource ) SAU ;

'4' $ GETFLDSTATE( -1, .RecordSource )

TABLEREVERT( .F., .RecordSource )

GO TOP IN ( .RecordSource )

ALTE

DELETE IN ( .RecordSource )

SKIP IN ( .RecordSource )

IF EOF()

GO BOTTOM IN ( .RecordSource )

ENDIF

ENDIF

*** Aflați care coloană este prima coloană

PENTRU FIECARE loColumn IN .Columns

DACĂ loColumn.ColumnOrder = 1

loColumn.SetFocus()

IEȘIRE

ENDIF

ENDFOR

SE TERMINA CU

ENDIF

Puteți obține o funcționalitate îmbunătățită setând proprietatea DeleteMark a grilei la true și apelând DeleteRecord din metoda Deleted a grilei. Este mult mai ușor să permiteți utilizatorului să anuleze o operațiune de adăugare fără a fi nevoit să treacă prin toată validarea care are loc atunci când încearcă să facă clic pe butonul de ștergere. De asemenea, permite utilizatorului să-și amintească o înregistrare dacă a șters una accidental. OK, deci ce este

dezavantajul? Este scump pentru că este necesar mai mult cod. De asemenea, aceasta nu este o soluție bună dacă RecordSource a rețelei este implicată în relații persistente. Rechemarea și ștergerea înregistrărilor în această situație ar putea avea unele consecințe interesante dacă utilizați declanșatoare pentru a menține integritatea referențială. Iată codul numit din metoda Deleted a grilei care șterge și reamintește înregistrările:

LPARAMETRI nRecNr

LOCAL llOK2Continuare, loColumn

llOK2Continuare = .T.

Cu asta

Înainte de a lua măsuri, trebuie să verificăm că suntem poziționați pe înregistrarea pentru a fi șters. Este posibil să faceți clic pe marcajul de ștergere din orice rând al grilei. Pointerul de înregistrare din RecordSource al grilei nu se mișcă până la finalizarea metodei Deleted. Aceasta înseamnă că, în acest moment, este posibil ca nRecNo, parametrul trecut la metoda Deleted, să nu fie același cu RECNO() al înregistrării curente. Cu toate acestea, mutarea necondiționată a indicatorului de înregistrare la nRecNo determină declanșarea AfterRowColChange al grilei. Setarea focalizării grilei după aceea pentru a o reîmprospăta determină declanșarea Validului grilei. Ambele evenimente fac ca validarea la nivel de rând să aibă loc. Dacă utilizatorul încearcă să șteargă o înregistrare pe care tocmai a adăugat-o din greșeală, nu dorim să aibă loc această validare. Vrem doar să inversăm înregistrarea. Și doar pentru a face lucrurile interesante, numărul de înregistrare al înregistrării nou adăugate este un număr negativ, în timp ce nRecNo este pozitiv:

SELECTAȚI Cust_ID de la Client WHERE nRecNo = RECNO( ) INTO CURSOR Temp

DACĂ _TALLY > 0

*** Nu este aceeași înregistrare... așa că mutați indicatorul de înregistrare.

IF Temp.Cust_ID # Client.Cust_ID

*** Asigurați-vă că nu suntem în mijlocul adăugării unei înregistrări și încercând

*** ștergeți sau rechemați unul într-unul diferit

IF .ValidateCurrentRow()

.Parent.SetFocus()

GO nRecNo IN ( .Recordsource )

.Seteaza focusul()

ALTE

llOK2Continuare = .F.

ENDIF

ENDIF

ENDIF

*** Deoarece înregistrarea nu este încă ștearsă

*** Acest lucru va funcționa pentru a decide dacă ne amintim de fapt o înregistrare

IF llOK2Continuare

DACĂ ȘTERS( .RecordSource )

RECALL IN ( .RecordSource )

*** Mutați indicatorul de înregistrare pentru a reîmprospăta grila

SKIP IN ( .RecordSource )

SKIP -1 IN ( .RecordSource )

ALTE

*** Verificați aici pentru a vedea dacă am fost în mijlocul adăugării acestei înregistrări

*** când ne-am întors și am decis să-l ștergem în schimb.

*** În acest caz, anulați adăugarea pentru a evita încălcările PK mai târziu

*** dacă decidem să-l amintim

IF '3' $ GETFLDSTATE( -1, .RecordSource ) SAU ;

'4' $ GETFLDSTATE( -1, .RecordSource )

TABLEREVERT( .F., .RecordSource )

GO TOP IN ( .RecordSource )

ALTE

DELETE IN ( .RecordSource )

*** Trebuie să faceți un TableUpdate imediat ce înregistrarea este ștearsă.

*** În caz contrar, atunci când este rechemat, veți primi o încălcare PK

DACĂ ! TABLEUPDATE ( 0, .F., .RecordSource )

MESSAGEBOX( „Nu se poate actualiza tabelul cu clienți”, 48, „Ne pare rău!”)

ENDIF

*** Trebuie să mutați indicatorul de înregistrare pentru a reîmprospăta afișajul

SKIP IN ( .RecordSource )

IF EOF( .RecordSource )

GO BOTTOM IN ( .RecordSource )

ENDIF

ENDIF

ENDIF

*** Reîmprospătați grila punând accentul pe aceasta

*** Aflați care coloană este prima coloană

PENTRU FIECARE loColumn IN .Columns

DACĂ loColumn.ColumnOrder = 1

loColumn.SetFocus()

IEȘIRE

ENDIF

ENDFOR

ENDIF

SE TERMINA CU

Cum adaug o casetă combinată la grila mea? (Exemplu: cboGrid::Ch06.vcx și cboInGrid.scx)

Mecanica de adăugare a unei casete combinate la o grilă este exact aceeași ca orice alt control. Cu toate acestea, o casetă combinată este destul de complexă în sine (a se vedea capitolul 5 pentru detalii despre caseta combinată) și integrarea funcționalității sale native cu o grilă poate fi dificilă. Cea mai mare problemă implică legarea coloanei grilei la o cheie străină din RecordSource în timp ce se afișează textul descriptiv asociat acesteia. Problemele secundare includ controlul aspectului grilei și furnizarea de navigare prin tastatură. Această secțiune prezintă o soluție elegantă la aceste probleme. Exemplul de cod inclus în acest capitol ilustrează această soluție folosind o combinație derulantă (Tip de afaceri), precum și o listă derulantă (Locații).

Figura 6.8 Caseta combinată într-o grilă
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Cea mai comună abordare utilizată atunci când adăugați o casetă combinată la o grilă este să setați proprietatea Sparse a coloanei la false. În timp ce acest lucru se ocupă de problema afișării textului descriptiv atunci când coloana este legată de o valoare cheie străină, dacă nu este o soluție bună. Când casetele combinate sunt afișate pe fiecare rând, grila pare aglomerată. În afară de aspectul inestetic (vezi Figura 6.9 de mai jos), există un Gotcha! asociat cu utilizarea acestei tehnici pentru a gestiona combo în interiorul grilelor. DisplayValue al combo-ului poate fi trunchiat deoarece InputMask implicit pentru coloana grilă este calculată pe baza lățimii ControlSourcei sale. Din fericire, soluția este simplă. Trebuie doar să specificați o mască de intrare pentru coloana suficient de largă pentru a găzdui valoarea DisplayValue a combo-ului. Din păcate, nu există

Cod client Nume 	client Tip afacere 		Locații	
BRIDGE 	Bridgestone/Fire staneAutomotive ServicesTUSAV
DEWEY 	Dewey, Cheetum și Howe Legal Drept civil/penal T 		V
DOOLITTLE 	Doolittle și DailyReal Estate/Property MgTUSAV
EUPHONY 	Euphony, Ltd.Telecomunicații 		T
			T 		T
JOE 	Joe's DinerRestaurantT 		▼
LETCHER 	Letcher și Scorer 		T 		v
MICRO 	MicrosoftSoftware DevelopmentTUSAv
IPOTECA 	Magazinul Ipoteca 		TUSAV
TIGHTLINE 	Tightline Computers, Ltd.Dezvoltare softwareT 		V
					
					
					

Adăugați client I șterge client | Salvare și ieșire |

-------------------------------------------------- -----------------------------------mod ușor de a pune această funcționalitate într-o clasă, deci este încă o altă sarcină care trebuie efectuată la nivel de instanță.

Figura 6.9 Combo-urile din fiecare rând par aglomerate

Când este necesară o casetă combinată într-o grilă, legăm grila la o vizualizare locală sau la un cursor actualizabil. Ne asigurăm că textul descriptiv asociat cheii externe este prezent în vizualizare sau cursor, așa că noi

poate lega coloana de asta. S-ar putea să vă întrebați cum actualizăm valoarea cheii externe în RecordSource al grilei. Folosim o clasă specială de casete combinate concepută pentru a rezolva această problemă. Codul este generic, deci poate fi implementat cu puțină suprasarcină suplimentară. Există doar câteva proprietăți pe care dezvoltatorul trebuie să le stabilească.

Proprietatea cFkField a combo-ului conține numele câmpului cheie străină din RecordSource al grilei care este asociat cu textul descriptiv legat de coloană. Proprietatea sa nFkColumn specifică numărul coloanei care conține valoarea cheii. Proprietatea opțională lAllowAddNew, atunci când este setată la true, permite utilizatorului să adauge intrări la RowSource din combo.

Am adăugat patru metode personalizate la clasa noastră de casete combinate de grilă: ProcessSelection, UpdateGridRecordSource, AddNewEntry și HandleKey. Metoda ProcessSelection a combo-ului, apelată din metoda sa Valid, apelează metoda sa UpdateGridRecordSource atunci când utilizatorul selectează o nouă valoare din combo. Dacă valoarea combo-ului nu s-a schimbat, nu este nevoie să actualizați RecordSource al grilei și să murdăriți bufferele. Această metodă invocă și metoda AddNewEntry atunci când este cazul. AddNewEntry este o metodă șablon și codul pentru a insera o înregistrare în tabelul de căutare trebuie adăugat la nivel de instanță, atunci când utilizatorului i se permite să adauge noi intrări din mers. Toată această activitate este coordonată prin următoarea metodă ProcessSelection:

Cu asta

*** Verificați pentru a vedea dacă am selectat o intrare validă în combo

DACĂ .ListIndex > 0

*** Dacă nu am schimbat valorile, nu actualizați recordSource al grilei

*** Nu vrem să murdărim tampoanele dacă nimic nu s-a schimbat

DACĂ .uOriginalValue # .Valoare

.UpdateGridRecordSource()

ENDIF

ALTE

*** Dacă nu, vezi dacă am tastat ceva în caseta combinată

*** care nu este în listă

DACĂ ! EMPTY( .DisplayValue )

*** adăugați noua intrare la RowSource al combo-ului

*** dacă permitem utilizatorului să adauge noi intrări din mers

DACĂ .lAllowAddNew

.AddNewEntry( )

ALTE

MESSAGEBOX( 'Vă rugăm să selectați o intrare validă în listă', 48, ;

„Selectare nevalidă” )

.Value = .uOriginalValue

ENDIF

ENDIF

ENDIF

SE TERMINA CU

Metoda UpdateGridRecordSource înlocuiește cheia externă din RecordSource din Grid cu cheia primară din RowSource al combo-ului. Deoarece elementele din lista internă a combo-ului sunt întotdeauna stocate ca date de caractere, trebuie mai întâi să convertim elementul din listă la tipul de date corect folosind funcția Str2Exp introdusă în Capitolul 2:

LOCAL lcField, lcTable

DACĂ !EMPTY( .cFKField ) ȘI !EMPTY( .nFKColumn )

lcTable = IIF( EMPTY( .cPrimaryTable ), ;

.Parent.Parent.RecordSource, .cPrimaryTable)

DACĂ GOL (lcTable)

CUTĂ MESAJE ;

( „TREBUIE să setați fie This.cPrimaryTable, SAU RecordSource a grilei



16, „Eroare dezvoltator!” )

ALTE

lcField = lcTable +

+ .cFKField

ÎNLOCUITĂ ( .cFKField ) CU ;

Str2Exp( .List[ .ListIndex, .nFKColumn ], ;

TYPE(lcField) ) IN (lcTable)

ENDIF

ENDIF

Ce altă funcționalitate specială ar trebui să aibă o casetă combinată când este în interiorul unei rețele? Credem că tastele săgeată sus și JOS ar trebui să permită utilizatorului să navigheze în grilă atunci când combo-ul este închis, dar ar trebui să permită și utilizatorului să parcurgă lista atunci când este aruncată. Metoda personalizată HandleKey a combo-ului este apelată din metoda KeyPress pentru a oferi această funcționalitate:

LPARAMETERS nKeyCode

LOCAL lnMaxRows, llRetVal

Cu asta

*** Dacă apăsați Escape sau Enter, lista nu mai este derulată

DACĂ nKeyCode = 27 SAU nKeyCode = 13

.lDroppedDown = .F.

ENDIF

*** Dacă lista nu este derulată, parcurgeți grila cu tastele cursorului

DACA !.lDroppedDown

CU .Părinte.Părinte

*** Calculați numărul maxim de rânduri din porțiunea vizibilă a grilei

lnMaxRows = INT( ( .Height - .HeaderHeight - ;

IIF( INLIST( .ScrollBars, 1, 3 ), SYSMETRIC( 8 ), 0 ) ) / .RowHeight )

*** Deplasați un rând în sus în grilă

DACĂ nKeyCode = 5 atunci

*** Dacă ne aflăm pe rândul de sus în partea vizibilă a grilei,

*** Derulați grila în sus cu un rând în cazul în care există o înregistrare anterioară

DACĂ .RelativeRow = 1

.DoScroll( 0 )

ENDIF

.ActivateCell( .RelativeRow - 1, .RelativeColumn )

ENDIF

*** Informați KeyPress că ne-am ocupat de apăsarea tastei

llRetVal = .T.

ALTE

*** Dacă ne aflăm pe rândul de jos în partea vizibilă a grilei,

*** Derulați grila în jos pe un rând în cazul în care există o înregistrare următoare

DACA nKeyCode = 24 ATUNCI

IF .RelativeRow >= lnMaxRows

.DoScroll( 1 )

ENDIF

.ActivateCell( .RelativeRow + 1, .RelativeColumn )

llRetVal = .T.

ENDIF

ENDIF

SE TERMINA CU

ENDIF

SE TERMINA CU

RETURN llRetVal

Mai există ceva pe care am putea dori să facem o casetă combinată într-o grilă? O îmbunătățire a evidentiilor este de a face ca fiecare rând de grilă să afișeze un set diferit de valori. Luați, de exemplu, grila pictnred în Figura 6.8. Este posibil ca fiecare client să aibă mai multe locații. Dacă imobilul pe ecran este la un nivel superior, aceste locații pot fi afișate într-o casetă combinată. Doar creați o vizualizare locală parametrizată a locațiilor în funcție de client. Setați RowSourceType din caseta combinată la 6-Fields și selectați câmpurile necesare pentru RowSource din caseta combinată. Un mic cod din metoda GotFocus a casetei combinate modifică conținutul RowSource pentru a afișa informațiile corecte pentru fiecare rând de grilă:

LOCAL lcGridAlias, vp_cl_key

DODEFAULT()

Cu asta

*** Solicitați vizualizarea locațiilor pentru a obține toate locațiile pentru

*** Clientul afișat în rândul curent al grilei

CU .Părinte.Părinte

.nRecNo = RECNO(.RecordSource)

lcGridAlias = .RecordSource

SE TERMINA CU

vp_cl_Key = &lcGridAlias . . Cl_Key

REQUERY( 'locație_lv' )

*** Reîmprospătați combo-ul

.Solicitare()

.Reîmprospăta()

SE TERMINA CU

Copyright 2000 de către Marcia Akins, Andy Kramek și Rick Schummer Toate drepturile rezervate

Concluzie

Sperăm că grilele sunt acum puțin mai puțin înțelese greșit decât atunci când ați început acest capitol. Nu putem spera să oferim toate răspunsurile, dar am încercat să oferim cât mai multe indicații și sugestii.
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Capitolul 7 - Lucrul cu date

„Este o greșeală capitală să teoretizezi înainte de a avea date.”

("Aventurile lui Sherlock Holmes" de Sir Arthur Conan Doyle)

Visual FoxPro este, în primul rând, un sistem de management al bazelor de date relațional (RDMS). A avut întotdeauna cel mai rapid și mai puternic motor de date disponibil pe o platformă de PC. Cu toate acestea, la fel ca toate instrumentele puternice de dezvoltare, Visual FoxPro se poate dovedi incomod dacă nu faci lucrurile așa cum se așteaptă. În acest capitol vom acoperi câteva dintre tehnicile și sfaturile pe care le-am învățat din lucrul cu date în Visual FoxPro.
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Tabelele în Visual FoxPro

Câteva elemente de bază

Unitatea de bază de stocare a datelor în Visual FoxPro este încă „fișierul DBF și fișierul „FPT” (câmp memo) asociat. Aceste fișiere își au rădăcinile în istoria limbajului xBase și formatul lor este încă recunoscut ca una dintre structurile standard de multe aplicații. Formatul de fișier DBF definește o înregistrare în termeni de un număr de câmpuri cu lungime fixă al căror tip de date este de asemenea definit. În ceea ce este considerat acum nomenclatura standard, câmpurile sunt denumite „Coloane” și înregistrările ca „Rânduri”, în timp ce fișierul DBF în sine este „Tabelul”. '

Tabelele din Visual FoxPro sunt întotdeauna stocate ca fișiere individuale (spre deosebire de Microsoft Access, de exemplu, unde tabelele există doar în interiorul fișierului bazei de date [MDB]) și pot exista fie ca tabele „libere”, fie „legate” la un container al bazei de date. Un tabel poate fi legat în orice moment numai la un singur container de bază de date și, în timp ce este legat de un container de bază de date, obține acces la atribute și funcționalități suplimentare care nu sunt disponibile atunci când este liber (consultați secțiunea despre containerul bazei de date din acest capitol pentru mai multe detalii). Cu toate acestea, dezlegarea unui tabel dintr-un container de bază de date cauzează pierderea irecuperabilă a acestor atribute și poate duce la probleme majore dacă se întâmplă într-un mediu de aplicație.

Limbajul Visual FoxPro are multe comenzi și funcții, care se ocupă de crearea, modificarea și gestionarea tabelelor (și a verilor lor apropiați, Cursore și Vizualizări). Partea 2 a Ghidului pentru programator Visual FoxPro (capitolele 5 până la 8) este dedicată lucrului cu date și acoperă destul de bine elementele de bază. Informații suplimentare despre modul în care funcționează efectiv comenzile individuale de gestionare a datelor pot fi găsite în „The Hackers Guide to Visual FoxPro 6.0” (Granor și Roche, Hentzenwerke Publishing, 1998).
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Cum să deschideți tabelul specific pe care doriți să îl utilizați

Când lucrați cu designerul de forme vizuale, nu există nicio problemă reală în identificarea unui tabel. Pur și simplu selectați tabelul prin intermediul casetei de dialog „Adăugați” numită din mediul de date al formularului. Cu toate acestea, atunci când trebuie să vă referiți la un tabel în mod programatic, lucrurile sunt mai dificile.

Comanda de bază USE <table> va deschide primul tabel cu numele specificat pe care îl găsește, conform următoarelor reguli:

• 	Dacă o bază de date este deschisă și este definită ca bază de date curentă, aceasta este căutată mai întâi.

• 	Dacă nicio bază de date nu este deschisă sau nici una nu este definită ca curentă, este utilizată calea normală de căutare FoxPro

Acest lucru are unele implicații pentru programator. Dacă un tabel cu același nume există în mai multe baze de date, trebuie să includeți o referință la baza de date atunci când deschideți acel tabel. Următorul cod arată cum funcționează:

INCHIDE TOT

DESCHIDEȚI BAZĂ DE DATE C:\VFP60\CH03\ch03

? SET('DATABASE') && returnează 'CH03'

DESCHIDEȚI BAZĂ DE DATE C:\VFP60\TIPSBOOK\DATA\tipsbook

? SET('DATABASE' ) && returnează 'TIPSBOOK'

USE clienti && Eroare - fișierul nu există!

USE ch03!clients && Deschide tabelul corect

Apropo, observați că deschiderea unei baze de date o setează și ca bază de date curentă! Observați, de asemenea, că deschiderea mai multor baze de date face ca ultima să fie deschisă actuală. Acest lucru trebuie urmărit atunci când accesați proceduri stocate sau utilizați funcții care funcționează pe baza de date setată în prezent (de ex

DBGETPROP() )

Cu toate acestea, dacă baza de date nu este deja deschisă și nu se află pe calea de căutare curentă, atunci nici măcar specificarea bazei de date nu va fi suficientă. Veți avea nevoie și de calea completă. Astfel, pentru a fi siguri că deschidem tabelul „Clienți” din baza noastră de date „CH03”, trebuie să folosim o comandă ca aceasta:

INCHIDE TOT

DESCHIDEȚI BAZĂ DE DATE C:\VFP60\TIPSBOOK\DATA\tipsbook

? SET('DATABASE' ) && returnează 'Tipsbook'

USE clienti && Eroare - fișierul nu există!

USE ch03!clients && Eroare - fișierul nu există

USE C:VFP60\CH03\ch03!clients && Deschide tabelul corect

Aceste reguli de căutare înseamnă, de asemenea, că, dacă un nume de tabel este folosit de două ori, o dată pentru un tabel dintr-un container de bază de date deschis și din nou pentru un tabel liber, atunci deschiderea tabelului liber prezintă o problemă, cu excepția cazului în care specificați o cale codificată ca parte a utilizării. comanda. Apropo, nu recomandăm această practică, este într-adevăr un design slab. Pur și simplu, nu există niciun mecanism, în afară de utilizarea unei căi explicite, pentru a spune Visual FoxPro că tabelul solicitat este un tabel liber și Visual FoxPro va căuta întotdeauna mai întâi containerul bazei de date deschise. Singura soluție pe care am găsit-o la această problemă este salvarea curentului

setarea bazei de date, apoi închideți baza de date, deschideți tabelul liber și, în final, restaurați setarea bazei de date, astfel:

IcDBC = SET('BAZA DE DATE')

SETARE BAZĂ DE DATE LA

USE <numele tabelului liber>

SETARE BAZĂ DE DATE LA (lcDBC)
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Cum să obțineți structura unui tabel

Introducerea containerului bazei de date ne-a permis în sfârșit să folosim nume lungi de câmp în Visual FoxPro (până la 128 de caractere, deși vechea limită de 10 caractere rămâne aplicabilă tabelelor gratuite). Deși acest lucru nu este neapărat un lucru bun (la urma urmei, avem și o proprietate Caption și un Comentariu pentru câmpurile din tabelele legate!), utilizarea numelor lungi de câmpuri s-a dovedit populară la mulți oameni. Problema mare este că vechile comenzi FoxPro care au structura tabelului de listă nu au ajuns din urmă - nici măcar în versiunea 6.0a. Atât comenzile LIST, cât și DISPLAY STRUCTURE sunt limitate la ieșire de 12 caractere pentru a duce la afișaje enervante precum următoarele:

Structura pentru tabel: C:\VFP60\CH07\JUNK.DBF

Număr de înregistrări de date: 0

Data ultimei actualizări: 02/10/1999

Pagina de cod: 1252

Câmp Nume câmp Tip Lățime Dec Index Colatează valorile nule

1 	THISISALONGF.. Personajul 10 Nr

2 	THISISALONGF.. Personajul 10 Nr

** Total ** 21

Puteți utiliza comanda COPY STRUCTURE EXTENDED TO <table> pentru a obține structura completă a tabelului, dar acest lucru creează probleme. În primul rând, trebuie să scoateți rezultatele într-un tabel - ceea ce înseamnă că trebuie să vă amintiți să ștergeți tabelul când ați terminat. În al doilea rând, tabelul de ieșire folosește câmpuri de memorare pentru o mare parte a datelor, astfel încât aveți și un fișier FPT cu care să vă ocupați, iar acest lucru face revizuirea informațiilor mai dificilă. Avantajul este că este ușor să modificați structura și puteți utiliza direct tabelul de ieșire pentru a crea un nou tabel.

Cu toate acestea, pentru a obține o listă simplă, cea mai bună soluție este să utilizați funcția AFIELDS() (care va primi numele complet al câmpului) și să scrieți o mică funcție pentru a înlocui comenzile vechi, și acum inadecvate, de listare a structurii. Un exemplu de astfel de funcție este inclus în exemplul de cod pentru acest capitol (vezi getStrul.prg) care produce, pentru același tabel, rezultatul de mai jos prin scrierea unui fișier text și apoi deschiderea fișierului într-o fereastră MODIFY FILE. (Desigur că acum aveți un fișier text de care scăpați, dar acesta, în opinia noastră, este mai puțin deranjant decât un tabel și este mai puțin probabil să provoace îngrijorare decât ștergerea fișierelor DBF și FPT din directorul dvs. de date):

Structura pentru: C:\VFP60\CH07\JUNK.DBF

Nume lung: UN NUME LUNG DE TABĂ POATE FI UTILIZAT AICI

Comentariu: Acesta este un tabel nedorit pentru a ilustra utilizarea numelor lungi de câmpuri

Definiții de câmp

THISALONGFIELDNAME C ( 10,0 ) NU NUL

Implicit: „ceva”

(Mesaj de eroare: VFP implicit)

Valabil: .NOT.EMPTY(acestalongfieldname)

(Mesaj de eroare: „Acest câmp nu poate fi lăsat gol”)

ACESTA LUNGNUMELE CÂMPULUI CARE DIFERIT C ( 10,0 ) NU NUL

Cu toate acestea, există mult mai multe informații care ar fi utile într-o listă. De exemplu, numele DBC din care provine tabelul ar fi util, la fel ca și numele oricăror fișiere asociate. Cel mai important ar fi foarte frumos să știm ce indici au fost definiți și pentru tabel. A doua variantă (GetStru2.prg) produce următorul rezultat:

Structura pentru: C:\VFP60\CH07\JUNK.DBF

DBC: CH07.DBC

CDX : JUNK.CDX

Notă: Fără fișier notă

Indici asociați

F02REG: ACESTA LUNGNUMELE CÂMPULUI DIFERIT

ISDEL: DELETED()

(Candidat): F03CAN: ACEST NUME LUNG CÂMPUL+ACEST NUME LUNG CÂMPUL ACEST DIFERIT

*** CHEIE PRIMARĂ: F01PRIME: THISALONGFIELDNAME

Informații de masă

Nume lung: UN NUME LUNG DE TABĂ POATE FI UTILIZAT AICI

Comentariu: Acesta este un tabel nedorit pentru a ilustra utilizarea numelor lungi de câmpuri

Fără regulă de masă

La inserare: on_insert()

La actualizare: on_update()

La ștergere: on_delete()

Detalii câmp

THISALONGFIELDNAME C ( 10,0 ) NU NUL

Implicit: „ceva”

(Mesaj de eroare: VFP implicit)

Valabil: .NOT.EMPTY(acestalongfieldname)

(Mesaj de eroare: „Acest câmp nu poate fi lăsat gol”)

ACESTA LUNGNUMELE CÂMPULUI CARE DIFERIT C ( 10,0 ) NU NUL

Această funcție poate fi apelată în câteva moduri. Mai întâi fără parametri, caz în care se presupune tabelul selectat curent (dacă există unul). Această metodă va funcționa atât cu cursoare, cât și cu vizualizări, în plus față de tabele! În al doilea rând, puteți trece un nume de FIȘIER (includeți extensia, dacă nu este doar „DBF) implicită) și va încerca să găsească fișierul, îl va deschide dacă nu este deja deschis, va întoarce structura și apoi va închide orice tabel pe care l-a deschis. în sine. În cele din urmă, îl puteți apela interactiv folosind:

GetStru2( GETFILE() )

- care va afișa dialogul pentru locația fișierului și pentru dvs.
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Cum se compară structurile a două tabele?

Uneori este necesar să știți dacă două tabele sunt de fapt identice ca structură, în special atunci când copiați date folosind comanda APPEND FROM care funcționează pe câmpuri care sunt numite același, indiferent de tipul sau dimensiunea datelor. Poate în mod ciudat pentru un sistem de baze de date, Visual FoxPro nu are nicio modalitate directă de a compara structura a două tabele, așa că trebuie să ne creăm propriul nostru. Următorul program (CompStru.prg) face exact acest lucru și în forma prezentată aici returnează o valoare logică simplă care indică dacă cele două tabele sunt sau nu identice. Cu toate acestea, ar fi o chestiune simplă ca această funcție să afișeze o listă a câmpurilor nepotrivite, dacă acest lucru ar fi necesar.

Această funcție trebuie apelată cu două nume de FIȘIER. Doar introducerea numelor ALIAS nu este suficientă, deoarece vom dori să folosim funcția fubo pentru a determina dacă fișierul fizic există și poate fi găsit. Nu putem presupune că toate fișierele vor avea de fapt o extensie „DBF”. (Pentru un exemplu de forțare a unei extensii vezi programul „GetStru2” din codul acestui capitol.):

**************************************************** ********************

* 	Program.CompStru

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Compară structura a două tabele **************************************** ********************************

LPARAMETERS tcFilel, tcFile2

LOCAL ARRAY laFields[1]

LOCAL lnSelect, lnCnt, lcFile, llRetVal

*** Am primit doi parametri

IF NOT ( ( VARTYPE( tcFilel ) = "C" AND ! EMPTY( tcFilel ) ) ;

AND ( VARTYPE( tcFile2 ) = "C" AND ! EMPTY( tcFile2 ) ) )

EROARE „9000: trebuie să treacă două nume de fișiere valide către CompStru()”

RETURNARE .F.

ENDIF

*** Verificați Parametrii pentru a vedea dacă fișierele specificate există

DACĂ NU ( FILE ( tcFilel ) ȘI FILE ( tcFile2 ) )

EROARE „9000: trebuie să treacă două nume de fișiere valide către CompStru()”

RETURNARE .F.

ENDIF

*** Acum asigurați-vă că ambele sunt tabele utilizabile

*** (ISDBF() este o funcție din 			acest program)			
DACĂ ! ISDBF(tcFilel 	)						
EROARE „9000: Fișierul „ 	+tcFilel+ „nu este utilizabil tabelul FoxPro”
RETURNARE .F.							
ENDIF							
DACĂ ! ISDBF(tcFile2 	)						
EROARE „9000: Fișierul „ 	+tcFile2+ „nu este utilizabil tabelul FoxPro”

RETURNARE .F.

ENDIF

*** Salvați zona de lucru curentă

InSelect = SELECT ()

SELECTARE 0

*** Creați un cursor temporar pentru compararea structurilor

CREATE CURSOR tmpstru ( ;

fnume C(10), ftip C(1), flen N(3,0), fdec N(3,0), fnul L(1) )

*** Deschideți fișierele pentru a compara și a introduce structurile în cursor

PENTRU lnCnt = 1 LA 2

lcFlle = ("tcFlle" + PADL(lnCnt,1))

UTILIZAȚI (&lcFlle) DIN NOU ÎN 0 ALIAS COMUNITAT TestFlle

AFIELDS( laFlelds, 'TestFlle' )

APPEND FROM ARRAY laFlelds

UTILIZAȚI ÎN TestFlle

URMĂTORUL

*** Acum vezi dacă câmpurile sunt ldentlcale

SELECT *, COUNT(*) cnt ;

DIN tmpstru ;

GROUP BY fname, ftype, flen, fdec, fnul ;

AVÂND cnt # 2 ;

INTO ARRAY junk

*** Return Loglcal T/F lf structura ls ldentlcal

SELECTARE (lnSelect)

UTILIZAREA IN tmpstru

llRetVal = (_TALLY = 0)

RETURN llRetVal

**************************************************** *****************

*** Verificați dacă o fișă poate fi deschisă ca masă

**************************************************** *****************

FUNCȚIA ISDBF(tcFlle)

LOCAL lcErrWas, llRetVal

*** Dlsable Error se gestionează temporar

lcErrWas = ON("EROARE")

LA EROARE *

*** Deschideți fișierul speclfled ca DBF

USE (tcFlle) ÎN 0 DIN NOU ALIAS testopen

*** Dacă a avut succes, a fost o masă vald

DACĂ FOLOSIT („TestOpen”)

llRetVal = .T.

UTILIZAȚI ÎN TestOpen

ENDIF

*** Restabiliți gestionarea erorilor și lucru

LA EROARE &lcErrWas

RETURN llRetVal

Iată, de altfel, o altă „ciudățenie”. Visual FoxPro nu include o funcție pentru a determina dacă un fișier este de fapt un tabel utilizabil. Deci din nou a trebuit să creăm una (funcția ISDBF()).

Acest lucru se bazează pe dezactivarea oricărei erori de gestionare și pe încercarea de a deschide fișierul - dacă reușește, putem presupune că fișierul este utilizabil ca tabel.
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Cum se testează prezența unui câmp într-un tabel

Acesta este unul complicat! Din nou, pare ciudat că nu există nicio funcție nativă care să facă acest lucru pentru noi, dar există (ca de obicei în Visual FoxPro) mai multe soluții posibile. Cu toate acestea, toți suferă de potențiale probleme. Iată câteva sugestii:

Testați pentru FSIZE()

Teoria de aici este că, dacă cereți lui Visual FoxPro dimensiunea unui câmp inexistent, acesta va returna 0.

Codul este într-adevăr foarte simplu:

DACA FSIZE('câmpul meu') > 0

*** Câmpul există în tabel, fă ceva

ENDIF

Cu toate acestea, rețineți că funcția FSIZE () (conform fișierului Ajutor):

„Returnează dimensiunea în octeți a unui câmp sau fișier specificat.”

Notați „SAU” de la sfârșitul acelei propoziții. În mod normal ne gândim la fsizeo ca returnând lățimea câmpului, dar nu întotdeauna face acest lucru! Setarea SET COMPATIBLE determină ce dimensiune este returnată (câmp sau fișier) și dacă compatibil este activat, atunci vei primi fie dimensiunea fișierului, fie o eroare dacă nu există niciun fișier cu numele pe care îl specificați.

Folosiți TYPE()

Această funcție va returna o valoare „U” dacă câmpul specificat nu există. Cu toate acestea, trebuie să adăugați numele aliasului pentru a vă asigura că VFP se uită de fapt la câmpul din tabel și nu la o variabilă numită la fel ca și câmpul dacă câmpul nu există.

IF TYPE( „junk.myfield” ) # „U”

*** Câmpul există în tabel, fă ceva

ENDIF

Există, totuși, un pericol real aici. Aceeași sintaxă a lui <alias.field> este folosită pentru a face referire la <object.property>, iar funcția typeo le va gestiona pe ambele cu o facilitate egală și vă poate oferi un răspuns total greșit. Nu este, așadar, o soluție bună!

De altfel, faptul că același stil de sintaxă este folosit atât pentru <object.property> cât și pentru <table.field> poate fi foarte util. Funcțiile JUSTSTEM() și JUSTEXT() au fost concepute pentru a extrage numele și extensia tabelului dintr-un nume de fișier, dar funcționează la fel de bine cu șirurile object.property - sau într-adevăr ORICE șir care conține un „."

Separator. (Faptul că fișierul Ajutor afirmă că JUSTEXT() returnează o „extensie de trei litere” este pur și simplu inexact, de fapt returnează toate caracterele la dreapta punctului din dreapta dintr-un șir, indiferent de lungime. În mod similar, JUSTSTEM() returnează toate caracterele la stânga punctului din dreapta dintr-un șir).

Utilizați VARTYPE()

Ce zici de utilizarea vartypeo în schimb? Această nouă funcție a fost introdusă în versiunea 6.0, dar în acest caz nu va funcționa deloc. Dacă specificați numele câmpului fără un alias, există aceeași posibilitate a unui fals pozitiv dacă există o variabilă și câmpul nu - chiar dacă Visual FoxPro va returna întotdeauna tipul câmpului dacă există ambele. Cu toate acestea, dacă specificați și aliasul (pentru a forța VFP să ignore variabile), veți obține o eroare „Variabila <numele> nu este găsită”, deoarece vartypeo nu evaluează lucrurile la fel ca tipul”.

Folosiți AFIELDS() și ASCAN()

Această abordare folosește funcția afieidso pentru a obține o listă cu toate numele câmpurilor (plus, după cum am văzut deja, mult mai multe informații) dintr-un tabel. Apoi ascano este folosit pentru a găsi domeniul pe care îl căutați. Dacă obțineți o potrivire, câmpul există:

InFieldCnt = AFIELDS(laFields, 'MyAlias')

DACĂ ASCAN(laFields, „MYFIELD”) > 0

*** Câmpul există în tabel, fă ceva

ENDIF

Acest lucru are avantajul simplității, dar suferă de două posibile gotchaT. Mai întâi, asigurați-vă că setarea exactă este activată și, de asemenea, formatați șirul pe care îl căutați în majuscule, altfel VFP ar putea găsi „CLINICAL” atunci când căutați de fapt „CLINIC”. De asemenea, deoarece ascano caută în toate coloanele, asigurați-vă că elementul pe care l-ați găsit este în prima coloană (adică numele câmpului). În caz contrar, este posibil să fi găsit doar o parte din codul de validare, comentariu sau un mesaj de eroare. În mod evident, puteți face ca această abordare să funcționeze fără aceste potențiale defecte, dar necesită mai mult cod decât ar părea necesar.

De exemplu, o metodă mai sigură, deși mai lentă, ar fi să folosiți afieidso și apoi să faceți o buclă prin matrice comparând prima coloană din fiecare rând cu numele câmpului pe care îl căutați folosind un „==" pentru comparație. Prin urmare,

lnFieldCnt = AFIEIDS(laFields, 'MyAlias')

FOR lnCnt = 1 TO lnFieldCnt

IF laFields[ lnCnt, 1 ] == 'MYFIEID'

*** Câmpul există în tabel, fă ceva

IEȘIRE

ENDIF

URMĂTORUL

Soluția fără ambiguitate

Cea mai fiabilă soluție este să utilizați fcounto pentru a controla o buclă și a verifica numele fiecărui câmp, așa cum este returnat de funcția fieldo, folosind dublu „=" pentru a forța o comparație exactă, după cum urmează:

FOR lnCnt = 1 TO FCOUNT()

IF UPPER( CÂMP (lnCnt) ) == 'CÂMPUL MEU'

*** Câmpul există în tabel, fă ceva

IEȘIRE

ENDIF

URMĂTORUL

Deși aceasta poate să nu fie cea mai rapidă metodă sau cea mai mică cantitate de cod, folosește doar funcții, care se referă în mod specific la câmpurile dintr-un tabel și vor reveni în mod fiabil indiferent dacă câmpul specificat există sau nu.
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Cum se verifică dacă un tabel este folosit de un alt utilizator

Visual FoxPro nu oferă această funcționalitate nativă, așa că trebuie să recurgem la șmecherie pentru a ne asigura că tabela pe care o alegem nu este deja utilizată de altcineva. De ce este important de știut acest lucru? De obicei, acest lucru este necesar atunci când scrieți rutine de întreținere care necesită utilizarea exclusivă a unui tabel. Soluția se bazează pe obținerea utilizării exclusive a tabelului specificat, pe baza că, dacă îl puteți obține, atunci tabelul nu este folosit de nimeni altcineva. Singura problemă posibilă este că, dacă aveți deja tabelul deschis cu modificări necomite în așteptare, le veți pierde și, în funcție de modul tampon, este posibil să primiți și o eroare. Cu toate acestea, considerăm că aceasta trebuie să fie responsabilitatea dvs. și că adăugarea de verificări pentru această situație complică inutil funcția. Iată funcția noastră IsInUse:

**************************************************** ********************

* 	Program. IsInUse.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Încearcă să obțină utilizarea exclusivă a unui tabel pentru a vedea dacă tabelul

* 	..........:este folosit de altcineva

**************************************************** ********************

LPARAMETERS tcTable

LOCAL lcTable, lcOldError, llRetVal, lnWasUsedIn, lnWasOrder

*** Verificați parametrii și asigurați-vă că este disponibil un tabel

IF EMPTY(tcTable) SAU VARTYPE(tcTable) # 'C'

MESSAGEBOX('Niciun tabel transmis către IsInUse()', 16, 'Se anulează...') RETURN

ALTE

lcTable = UPPER( ALLTRIM( tcTable ))

ENDIF

*** Dacă avem deja tabelul în uz, închideți-l și observați faptul! llWasUsedHere = USED( lcTable )

DACA A FOST FOLOSITAICI

*** Îl folosim, așa că află unde și salvează-l

lnWasUsedIn = SELECT (lcTable)

lnWasOrder = ORDER( lcTable )

lnWasRec = IIF( RECNO( lcTable ) > RECCOUNT( lcTable ), ;

RECCOUNT(lcTable), RECNO(lcTable))

UTILIZARE ÎN (lcTable)

ALTE

lnWasedIn = 0

lnWasOrder = 0

lnWasRec = 0

ENDIF

*** Salvați gestionarea actuală a erorilor și dezactivați-o temporar

lcOldError = ON( „EROARE” )

ON ERROR llRetVal = .T.

*** Încercați să utilizați tabelul în mod exclusiv

UTILIZAȚI ( lcTable ) ÎN 0 EXCLUSIV

*** Dacă am reușit, închide-l din nou

DACĂ ! llRetVal

UTILIZARE ÎN (lcTable)

ENDIF

*** Restaurați gestionarea erorilor

ON ERROR &lcOldError

*** Dacă a fost deschis, atunci resetați-l corespunzător

DACA A FOST FOLOSITAICI

UTILIZAȚI ( lcTable ) DIN NOU ÎN ( lnWasedIn ) ORDER ( lnWasOrder )

DACĂ LnWasRec # 0

*** A fost pe o înregistrare anume

GOTO (lnWasRec) IN (lcTable)

ALTE

*** Mergeți doar la prima înregistrare disponibilă

GO TOP IN (lcTable)

ENDIF

ENDIF

*** Întoarceți rezultatul

RETURN llRetVal

Observați că, dacă avem deja tabelul deschis în propria noastră sesiune, îl restabilim la finalizare. Este posibil ca acest lucru să nu fie de fapt valid, deoarece se presupune că utilizarea acestei funcții ar fi imediat anterioară unei comenzi de utilizare exclusivă, care ar eșua oricum deoarece mai avem tabelul deschis. Cu toate acestea, oferă o oportunitate potrivită de a arăta cum să restaurați un tabel, așa că am lăsat această funcționalitate în loc. Dacă nu îl doriți, eliminați-l!

O problemă apare atunci când tabelul necesar este deja deschis într-o altă zonă de lucru sub un alias diferit sau când există un cursor generat SQL care este de fapt o vizualizare filtrată a unui tabel deschis cu un alias diferit pe stația de lucru curentă. Funcția se bazează pe funcția nativă Visual FoxPro USED() care testează doar „aliasul” specificat. În oricare situație, funcția va returna False (indicând corect că tabelul este deja în uz), dar încercările ulterioare de a găsi aliasul vor eșua cu o eroare „Alias nu a fost găsit”, așa cum ilustrează următoarele fragmente de cod:

*** Deschideți Tabelul sub alias diferit

USE clienți ALIAS fred

? ISINUSE( 'clienti' ) && RETURNE .T.

SELECTAȚI clienți && EROARE: „Alias CLIENTS nu a fost găsit”

*** Creați vizualizare filtrată din tabel cu alias diferit

USE clienți ALIAS fred

SELECT * FROM fred WHERE clisid = 96 INTO CURSOR joe && Creează o vizualizare filtrată

USE IN fred && Închide „clienți”

? ISINUSE( 'clienti' ) && RETURNE .T.

SELECTAȚI clienți && EROARE: „Alias CLIENTS nu a fost găsit”

Aceasta ar putea fi o problemă în anumite circumstanțe, dar trebuie să ne uităm la utilizarea intenționată pentru această funcție - care este de a determina dacă tabelul specificat este utilizat de un alt utilizator. Scenariul prezentat mai sus ar putea fi rezolvat pe o singură stație de lucru folosind funcția AUSED() pentru a obține o matrice

a tuturor alias-urilor utilizate în DataSession curent. Fiecare alias ar putea fi apoi testat folosind funcția DBF() pentru a obține numele tabelului de bază și întreaga operație inclusă într-o buclă pentru a testa toate sesiunile de date deschise. Dar acest lucru nu ar putea fi aplicat la stația de lucru a altui utilizator, așa că vedem puțină valoare în creșterea complexității funcției. La urma urmei, nu contează cum este folosit tabelul, această funcție are scopul de a ne spune că este în uz undeva.
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Ce este mai exact un cursor?

Termenul „cursor” este un acronim derivat din expresia „CURrent Set Of Records”. În Visual FoxPro, un cursor este implementat ca fișier temporar care este creat în orice director la care este indicat variabila de sistem tmpfiles (dacă nu a fost specificată nicio setare tmpfiles, directorul de pornire VFP este utilizat în mod implicit). Cursoarele sunt, prin urmare, foarte utile pentru păstrarea datelor tranzitorii, deoarece Visual FoxPro le va curăța pentru dvs.

Un cursor poate fi creat în două moduri - mai întâi prin executarea unei instrucțiuni SQL Select, care include clauza into cursor <nume>. În toate versiunile FoxPro până la versiunea 6.0 inclusiv, acest lucru creează întotdeauna un cursor numai pentru citire și vom avea mai multe de spus despre cursorii generați de SQL în capitolul dedicat SQL. Pentru moment, vom observa pur și simplu că crearea unui cursor în acest fel deschide și tabelul sursă într-o zonă de lucru liberă, dacă nu este deja utilizat.

În al doilea rând, prin utilizarea uneia dintre variantele comenzii CREATE CURSOR. Acest lucru produce un cursor de citire/scriere care este, pentru toate scopurile practice, imposibil de distins de un tabel standard. Pe acest tip de cursor ne vom concentra în această secțiune. (Rețineți că, indiferent de modul în care este creat un cursor, acesta este întotdeauna creat explicit pe sistemul local al utilizatorului și este întotdeauna exclusiv pentru utilizatorul respectiv.)

Cum se creează un cursor pe baza unui tabel existent

Probabil cea mai simplă modalitate de a crea un cursor este să-l bazezi pe un tabel existent. Am folosit deja funcția AFIELDS ( ) de mai multe ori în acest capitol (și, fără îndoială, o vom folosi din nou!) pentru a obține detaliile structurii unui tabel într-un tablou. Matricea pe care o produce poate fi folosită direct pentru a crea un cursor (și da, deși un cursor este de fapt un tabel „liber”, poate găzdui nume lungi de câmpuri) folosind comanda:

CREATE CURSOR <aliasname> FROM ARRAY <arrayname>

Cu toate acestea, există o problemă! in acest! Dacă tabelul utilizat ca sursă pentru funcția afieldso este legat de o bază de date, atunci TOATE informațiile adunate despre acel tabel sunt transferate la cursorul țintă - inclusiv detalii precum numele lung al tabelului, declanșatorii și valorile implicite. Acest lucru va cauza probleme, așa că am creat o mică funcție pentru a face un cursor bazat pe un tabel care primește doar informațiile structurale necesare (CreCur.prg). Această funcție necesită transmiterea unui nume de tabel valid pentru sursă, dar va genera un nume implicit de cursor („Cur_” + numele tabelului) dacă nu specificați un nume de cursor:

**************************************************** ********************

* Program.

: CreCur.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Abstract...: creează un cursor pe baza structurii tabelului numit

* 	..........: Îndepărtează orice în afară de informațiile structurale de bază

**************************************************** ********************

LPARAMETERS tcSceTable, tcCursorName

LOCAL laFields[1]

LOCAL lcTable, lcTgtCur, lnSelect, llWasOpen, llRetVal, lnFields

LOCAL lnRow, lnCol

MAGAZIN .T. TO llWasOpen, llRetVal

*** Curățați parametrii și asigurați-vă că este disponibil un tabel

IF EMPTY(tcSceTable) SAU VARTYPE(tcSceTable)#'C'

lcTable = ALIAS()

ALTE

lcTable = UPPER(ALLTRIM(tcSceTable))

ENDIF

IF EMPTY(lcTable)

MESAGEBOX('Niciun tabel trecut sau deschis', 16, 'Se anulează...')

ÎNTOARCERE

ENDIF

*** Salvați zona de lucru curentă (comanda de creare a cursorului o va schimba!)

lnSelect = SELECT ()

*** Deschide masa dacă este necesar și notează faptul!

DACĂ ! FOLOSIT(lcTable)

UTILIZAȚI (lcTable) ÎN 0

llWasOpen = .F.

ENDIF

*** Numele cursorului este implicit dacă nu a trecut niciunul

IF EMPTY(tcCursorName) SAU VARTYPE(tcCursorName)#'C'

lcTgtCur = „CUR_” + UPPER(ALLTRIM(lcTable))

ALTE

lcTgtCur = UPPER(ALLTRIM(tcCursorName) )

ENDIF

*** Obțineți structura tabelului

lnFields = AFIELDS( laFields, lcTable )

*** Acum golește totul după Coloana 6 a matricei

FOR lnRow = 1 TO lnFields

FOR lnCol = 7 TO ALEN( laFields, 2 )

laFields[ lnRow, lnCol ] = ""

URMĂTORUL

URMĂTORUL

*** Creați cursorul

CREATE CURSOR (lcTgtCur) DIN ARRAY laFields

*** Obțineți valoarea de returnare

llRetVal = USED (lcTgtCur )

*** Faceți ordine

DACĂ ! a fost deschis

USE IN (tcSceTable)

ENDIF

SELECTARE (InSelect)

RETURN ILLetVal

Când poate fi folosit un cursor?

Odată ce cursorul a fost creat, îl puteți folosi ca și cum ar fi de fapt un tabel. Poate fi indexat, folosit ca sursă pentru o selecție SQL, RecordSource pentru o grilă sau RowSource pentru o listă sau o casetă combinată. Singurul lucru de reținut este că anumite operațiuni necesită numele fișierului real în loc de alias și, în acele cazuri, trebuie să utilizați funcția dbfo pentru a vă asigura că Visual FoxPro citește corect cursorul. De exemplu, pentru a adăuga dintr-un cursor într-un tabel fizic, trebuie să utilizați sintaxa:

APPEND FROM DBF( '<CursorName>' )

în loc de APPEND FROM <CursorName>

Cea mai obișnuită utilizare pentru un cursor este în situațiile în care altfel ați avea nevoie de un tabel temporar. Avantajul unui cursor este că nu va rămâne pe sistemul dvs. odată ce Visual FoxPro s-a închis și nu trebuie să vă faceți griji că îl ștergeți sau că directorul de date este umplut cu tabele temporare. Singura excepție de la aceasta este atunci când Visual FoxPro se termină anormal (un alt eufemism pentru „crashes”). În aceste circumstanțe, cursoarele nu vor fi șterse automat. Totuși, este ușor să le găsești, verificând data și ora creării și apoi pur și simplu ștergându-le manual.

De exemplu, dacă trebuie să importați date dintr-o sursă externă, să o validați și apoi să adăugați doar înregistrările valide la un tabel fizic, un cursor este intermediarul ideal tocmai pentru că poate fi tratat ca și cum ar fi tabelul „real”.
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Indecși în Visual FoxPro

A spune că indexurile sunt importanți atunci când lucrați cu date în Visual FoxPro este o „subestimare”. Viteza și flexibilitatea lucrului cu date sunt guvernate, în mare măsură, de modul în care vă configurați și utilizați indexurile. Tocmai pentru că indicii sunt atât de importanți, încât există adesea tentația de a indexa totul dintr-un tabel. La fel ca în majoritatea lucrurilor, totuși, prea mult este la fel de rău ca și prea puțin. Ne limităm aici observațiile în mod specific la utilizarea indicilor structurali și am inclus o notă despre unele dintre problemele asociate cu indici autonomi mai târziu în acest capitol.

Mai întâi trebuie să ne reamintim câteva reguli de bază care guvernează indici.
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Tipuri de indici

Visual FoxPro oferă patru tipuri de bază de indici, după cum este ilustrat de următorul tabel:

Tip 	CaracteristiciComentarii
Primar 	Se aplică numai tabelelor legate Doar un singur index primar per tabel Indexul impune unicitatea cheilor Folosit de Visual FoxPro pentru a gestiona relațiile persistente dintre tabele Identificați capătul „unu” al unei relații unu-la-mai multe
Candidatul 	Se aplică atât tabelelor libere, cât și celor legate Poate defini mai mulți indecși candidați. Indexul impune unicitatea cheilor. Numiți așa, deoarece astfel de indici sunt „candidați” care trebuie transformați în chei primare. Identificați capătul „unu” al unei relații unu-la-mai multe
Regular 	Se aplică atât la tabelele libere, cât și la cele legate. Poate defini mai mulți indecși obișnuiți. Orice valoare cheie poate fi indexată indiferent dacă este unică sau nu. Indexul standard Visual FoxPro Identifică capătul „mai multe” al unei relații unu-la-mai multe
Unic 	Se aplică atât la tabelele libere, cât și la cele legate. Poate defini mai mulți indecși unici. Numai prima apariție a unei valori cheie este indexată, indiferent dacă este unică sau nu.

Tabelul 7.1 Tipuri de index Visual FoxPro

Există câteva reguli care se aplică pentru crearea tuturor tipurilor de index, după cum urmează:

• 	Numărul maxim de octeți dintr-o cheie de index pentru indici compacti este de 240, pentru indecșii necompacți limita este redusă la 100 de octeți per cheie.

• 	Indecșii filtrati (adică cei ale căror chei includ expresii cu clauze pentru sau nu) nu pot fi utilizați pentru a optimiza operațiunile care utilizează tehnologia Rushmore.

• 	Dacă tabelul acceptă valori nule, este necesar un octet suplimentar per valoare de cheie, reducând lungimea maximă a șirului de chei.

• 	SET COLLATE afectează modul în care sunt stocate cheile index. Dacă se utilizează setarea implicită („mașină”), fiecare caracter din cheie necesită un octet. Toate celelalte setări necesită doi octeți per caracter.

• 	Setarea SET COLLATE determină ordinea de sortare utilizată de Visual FoxPro.
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Cum să obțineți informații despre un index

Visual FoxPro oferă o serie de funcții care returnează informații despre indecșii asociați unui tabel, așa cum este ilustrat în următorul tabel:

Funcția 	Returnează
KEY() 	Expresia cheie index pentru o etichetă specificată sau eticheta de control curentă dacă nu este specificată nici una
TAG() 	Numele etichetei care corespunde numărului specificat sau eticheta de control curentă dacă nu este specificată niciuna
TAGNO() 	Numărul etichetei al cărei nume a fost specificat sau eticheta de control curentă dacă nu este specificată nici una
TAGCOUNT() 	Numărul de etichete index din indexul compus asociat tabelului
CANDIDATE() 	Returnează valoarea logică care indică dacă numărul etichetei specificat este o cheie candidată
PRIMARY() 	Returnează valoarea logică care indică dacă numărul etichetei specificat este o cheie primară
ORDER() 	Numele etichetei de index care controlează în prezent
SYS(14) 	Numele pentru numărul de etichetă specificat (echivalent cu KEY())
SYS(21) 	Numărul etichetei de index care controlează în prezent (echivalent cu TAGNO())
	

SYS(22)

Numele etichetei de index care controlează în prezent (echivalent cu ORDER())

SYS(2021) 	Expresia filtrului pentru numărul de etichetă specificat (dacă există)

Tabelul 7.2 Funcții care returnează informații despre indici

După cum puteți vedea, singura informație pe care nu o puteți obține este dacă un index a fost creat în ordine ascendentă sau descendentă și acest lucru oricum nu contează cu adevărat, deoarece orice index poate fi inversat adăugând în mod specific cuvântul cheie ascendent sau descendent la comanda SET ORDER . Luați în considerare următoarele:

UTILIZAȚI CLIENȚI ETICHETA COMANDĂ

MERGI SUS

LISTĂ URMĂTOARELE 3 clisid && UTILIZAȚI clienți ETICHETA COMANDĂ MERGI SUS

LISTĂ URMĂTOARELE 3 clisid &&

clisid ASCENDENTE

Returnează 96, 97, 98 clisid DESCENDENT

Returnează 186, 185, 184
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Cum se testează existența unei etichete index

Cea mai simplă situație aici este atunci când cunoașteți numele etichetei pentru care trebuie să testați. În acest caz, puteți utiliza pur și simplu funcția taghoo pentru a returna numărul de index al numelui. Dacă valoarea returnată este mai mare decât 0, eticheta există, altfel nu există. Prin urmare:

DACĂ TAGHO ( „eticheta mea”, „tabelul meu”) > 0

*** Eticheta există pentru tabelul specificat

ENDIF

Lucrurile devin mai complexe dacă nu cunoașteți numele etichetei, dar trebuie să știți dacă există un index pentru o anumită expresie. În acest caz, trebuie să parcurgeți toate etichetele și să verificați expresia KEY() folosind cod ca acesta:

lcTagName = ""

FOR lnCnt = 1 la tagcouht()

IF UPPER( ALLTRIM( KEY(lnCnt) ) ) == <expresie de găsit>

lcTagName = TAG( lnCnt )

Ieșire

ENDIF

URMĂTORUL

RETURN lcTagName
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Utilizarea cheilor candidate (și primare).

Caracteristica esențială a tuturor indecșilor care au fost definiți ca candidat (inclusiv cheia candidată care poate fi definită, pentru un tabel legat, ca „primar”) este că responsabilitatea asigurării unicității cheilor este gestionată de procesul de indexare însuși. Sună minunat - nu mai există cod pentru a verifica dacă o cheie nu există deja. Există, desigur, o captură - la urma urmei, ce poate face Visual FoxPro dacă constată că cheia de index este o duplicare în timp ce adaugă o înregistrare nouă? Răspunsul este să faci exact ceea ce face - să ridici o eroare și să respingi adăugarea. Consecința este că, în calitate de dezvoltatori, trebuie să ne asigurăm că cheia pe care o oferim VFP este unică atunci când folosim indici candidați. Acest lucru ridică două probleme, mai întâi cum să gestionați cheile care sunt generate de sistem (de obicei ca chei „surogat”) și al doilea cum să gestionați cheile care sunt introduse direct de un utilizator.
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Ce este o „cheie surogat”?

O cheie surogat nu are nicio semnificație comercială și este pur și simplu o valoare stocată într-un anumit câmp cu scopul exclusiv de a identifica în mod unic acel rând din tabel. De obicei, este pur și simplu o valoare întreagă generată automat de sistemul însuși atunci când o înregistrare nouă este adăugată la un tabel. S-ar putea să vă întrebați, în acest moment, de ce nu folosim pur și simplu numărul de înregistrare, deoarece acesta identifică deja în mod unic o înregistrare. (Evident că nu putem avea două înregistrări cu același număr de înregistrare în același tabel.)

Motivul este că numărul de înregistrare din Visual FoxPro este „pozițional” (adică identifică locația fizică din fișier) și nu are legătură cu conținutul real al înregistrării. Anumite comenzi din Visual FoxPro schimbă locația fizică a înregistrărilor într-un tabel (de exemplu, împachetați și sortați), în timp ce dacă extrageți date din fișier într-un cursor sau vizualizați numărul de înregistrare generat pentru setul de rezultate nu se va potrivi cu numărul de înregistrare din masa originala. Aceste probleme sunt evitate dacă cheia face de fapt parte din datele conținute de înregistrare.

Cheile surogat au două funcții, ambele legate de faptul că identifică în mod unic înregistrările. Mai întâi, ele pot fi folosite ca cheie pentru indexul primar pentru tabelele care acționează ca părinte în relațiile persistente și ca chei externe în tabelele înrudite. În al doilea rând, ele pot fi folosite pentru unirea tabelelor la construirea instrucțiunilor SQL.

Cum ar trebui să implementez cheile surogat?

În primul rând, structurile tabelului trebuie să includă câmpuri pentru chei. Cea mai simplă (și cea mai obișnuită) implementare folosește un tip de date INTEGER. Acest tip de date necesită doar 4 octeți de stocare per înregistrare și permite valori în intervalul -2.147.483.647 până la 2.147.483.647 (un interval de aproximativ 4 miliarde) - care ar trebui să fie suficient pentru majoritatea scopurilor practice.

Când proiectați tabele care vor folosi chei surogat pentru a menține relațiile, veți avea nevoie de cel puțin două câmpuri suplimentare. Unul în tabelul părinte pentru a stoca ID-ul real al înregistrării („cheia primară”) și unul în fiecare tabel copil pentru ID-ul înregistrării corespunzător din tabelul părinte („Cheia străină”). Au fost înaintate diverse propuneri pentru denumirea unor astfel de câmpuri și nu există un răspuns „corect”. Cel care ne place folosește „xxxSID” pentru o cheie primară (unde „xxx” este identificatorul tabelului, iar „SID” înseamnă „System ID”) și, în fiecare tabel asociat include un câmp numit „xxxKeÿ” (unde „xxx” se referă din nou la tabelul care deține ID-ul sistemului, iar „KEY” indică că aceasta este o cheie străină pentru acel tabel). Alte convenții sugerează adăugarea sufixului „PK” sau „FK” la numele câmpului, după caz. Chiar nu contează cum vă denumiți cheile, dar este important să adoptați o convenție și să fiți consecvenți în utilizarea acesteia. Figura 7.1 prezintă o structură relațională tipică folosind chei primare/străine numite în modul nostru preferat:

Figura 7.1 Structura relațională folosind chei surogat

Puteți vedea din diagramă că pentru a obține o listă a tuturor comenzilor pentru un anumit client, se poate construi o instrucțiune SQL ca aceasta:

SELECT <fieldList> ;

FROM Client CU JOIN Comenzi SAU ;

ON OR.cuskey = CU.cussid ;

UNDE CU.cussid = <valoare> ;

INTO CURSOR cur_OrdList

Nu numai că acest lucru face unirea tabelelor destul de simplă, dar prin includerea câmpurilor SID din fiecare tabel în setul de rezultate, aveți o cale imediată și neechivocă înapoi la datele sursă la toate nivelurile, în orice moment. Acest lucru este extrem de util în situațiile în care furnizați utilizatorului liste de date pentru a selecta un anumit articol pentru lucrul ulterioar. Cheia surogat indică direct înregistrările necesare.

În cele din urmă, ar trebui să definiți și un index pe cheia surogat ca cheie primară pentru fiecare tabel. Acest lucru are mai multe beneficii:

• 	Evită necesitatea cheilor compuse. Cheia surogat identifică întotdeauna o singură înregistrare

• 	Puteți utiliza o cheie generată automat, care va fi întotdeauna unică și astfel evitați nevoia de a verifica dacă există chei duplicate atunci când adăugați o înregistrare.

• 	Câmpul cheie nu trebuie să fie văzut de utilizator și cu siguranță nu trebuie să fie editabil, simplificând codul necesar pentru a menține integritatea referențială între tabele.

Cum generez chei surogat?

Credem că cea mai bună soluție este să folosiți chei întregi și să folosiți la nivel de câmp Implicit pentru câmpul cheie pentru a apela o procedură pentru a genera următorul număr în secvență. Procedura poate fi fie o procedură autonomă, inclusă într-un fișier de procedură, fie o procedură stocată într-un container de bază de date. Preferăm să păstrăm procedura ca procedură stocată într-un container de bază de date (fie doar pentru că dacă un tabel este deschis în afara aplicației și este inserată o nouă înregistrare, prezența DBC va asigura inserarea corectă a noii valori a cheii). Deci, cum ar trebui să arate această procedură și cum ar trebui să fie numită?

Setarea pentru valoarea implicită în designerul de tabel este într-adevăr foarte simplă. Tot ceea ce este necesar este un apel la o funcție care va returna valoarea de inserat. Am inclus un tabel numit „Clienți” în baza de date CH07, care are un câmp de cheie surogat „clisid”, care este folosit ca cheie primară pentru tabel. (Întotdeauna încercăm să denumim etichetele noastre de index, astfel încât să indice câmpul pe care se bazează. Este mai ușor să vă amintiți numele cheii!) Acest câmp are o valoare implicită definită care apelează procedura stocată NEWID() pentru a returna următoarea cheie disponibilă când este inserată o nouă înregistrare. Observați că apelul funcției include numele tabelului pentru care este necesară cheia:

Μ Clienti Table Designer

Figura 7.2 Cum se configurează o valoare implicită pentru o cheie primară secvenţială

Procedura reală se bazează pe prezența unui tabel care menține o listă a tuturor tabelelor din baza de date și ultima valoare a cheii primare care a fost atribuită fiecăruia. Calim acest tabel „SYSTABLE” și are următoarea structură (de fapt, includem, de obicei, mult mai multe informații legate de tabel în systable, dar aceasta este tot ceea ce este necesar pentru generarea cheilor primare.):

Structura pentru: C:\VFP60\CH07\SYSTABLE.DBF

DBC: CH07.DBC

CDX : SYSTABLE.CDX

Notă: Fără fișier notă

Indici asociați

*** CHEIE PRIMARĂ: CTABLE : CTABLE

Informații de masă

Nume lung: SYSTABLE

Comentariu: Tabel de sistem pentru înregistrarea utilizării cheii primare

Detalii câmp

CTABLE C ( 8,0 ) NU NUL

ILASTKEY I ( 4,0 ) NU NUL

Funcția Newld() este destul de simplă și este listată mai jos. Punctele de remarcat sunt că systable este deschis fără tamponare (evitând astfel necesitatea de a utiliza un TableUpdate() ) și este blocat în mod explicit

înainte ca noua valoare a cheii să fie obținută (astfel încât să funcționeze fiabil într-un mediu multi-utilizator). De asemenea, funcția se auto-corectă. Dacă uitați să adăugați un nou tabel la listă, prima dată când o înregistrare este inserată în acel tabel, o înregistrare nouă va fi inserată automat în systable. Cu toate acestea, deși este utilă în dezvoltare, a face ca această funcție să se auto-corecte nu este neapărat un lucru bun într-un mediu de aplicație. Însuși actul de a se corecta poate ascunde faptul că a apărut o problemă gravă în baza de date a unui sistem! Exemplul de aici arată versiunea dezvoltatorului:

FUNCȚIE newid(tcTable)

LOCAL lcTable, lnNextVal, InOldRepro

*** Verificați Param și convertiți-l în majuscule

IF EMPTY(tcTable) SAU TYPE( „tcTable” ) # „C”

RETURNARE 0

ENDIF

lcTable = UPPER(ALLTRIM( tcTable ))

*** Salvați setările și deschideți Systable dacă nu este deja deschis

lnOldRepro = SET('REPROCESARE')

DACĂ ! FOLOSIT('stable')

UTILIZAȚI systable IN 0

*** Asigurați-vă că tabelul nu este tamponat

=CURSORSETPROP( 'Buffering', 1, 'systable' )

ENDIF

*** Acum găsiți tabelul necesar

IF SEEK(lcTable, 'systable', 'cTable' )

*** Am găsit tabelul necesar

*** Obțineți un blocare pe systable

SETATI REPROCESAREA LA AUTOMAT

IF RLOCK( 'systable' )

*** Obțineți următoarea valoare și actualizați systable

lnNextVal = systable.iLastKey + 1

ÎNLOCUIȚI iLastKey cu lnNextVal IN systable

DEBLOCARE IN systable

ALTE

*** Acest lucru nu ar trebui să se întâmple NICIODATĂ!

lnNextVal = 0

ENDIF

ALTE

*** Tabelul nu a fost găsit!

*** Necesită o nouă intrare în systable

lnNextVal = 1

INSERT INTO systable (cTable, iLastKey) VALUES ( lcTable, lnNextVal )

ENDIF

*** Returnați un nou ID

SETARE REPROCESARE LA (lnOldRepro)

RETURN lnNextVal

ENDFUNC

Asta e tot ce este în ea. Această funcție poate fi găsită ca procedură stocată în baza de date CH07. Ori de câte ori o înregistrare este atașată la tabelul Clienți, i se va atribui automat următorul ID în secvență.

Ce fac dacă un utilizator anulează o adăugare?

Răspunsul scurt este „Nimic!” Veți fi realizat că această abordare înseamnă că un nou ID este adăugat la o înregistrare de îndată ce acea înregistrare este atașată la tabel. Dacă nu comiteți acea nouă înregistrare, ID-ul este „irosit” - nu există nicio funcționalitate pentru a recupera ID-ul utilizat și nici o astfel de funcționalitate nu este de dorit. Într-un mediu cu mai mulți utilizatori, încercarea de a recupera un ID pierdut este tocmai chestia din care se fac coșmaruri și, dacă așa cum am sugerat, utilizați o cheie întreagă, aveți aproape 2 miliarde de valori cu care să vă jucați (chiar dacă ignorați valorile mai mic de 0).

Mai important, deoarece ID-ul pe care îl atribuiți este un ID surogat, pur și simplu nu contează dacă numerele sunt în afara secvenței sau dacă există lacune în secvență. Amintiți-vă, singura funcție a cheii este de a identifica înregistrarea acesteia!
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Gestionarea cheilor introduse de utilizator

După cum sa indicat deja, susținem cu tărie utilizarea cheilor surogat pentru gestionarea integrității referențiale și ca bază pentru referirea datelor în interogări și declarații SQL. Cu toate acestea, există încă situații în care utilizatorii trebuie să poată introduce valori unice (imi vin în minte numerele de comandă și de factură). Pentru acestea, indicele candidat este ideal dacă ne putem asigura că astfel de valori sunt de fapt unice atunci când încercăm să facem modificări în tabele.

Desigur, nu există nicio modalitate absolută de a împiedica utilizatorii să introducă valori duplicate, deoarece avem de-a face cu date care sunt perfect valide - doar că în acest context se întâmplă să fie greșite. Este axiomatic că nu există o soluție software la problema datelor valide, dar greșite! Prin urmare, va trebui totuși să gestionați erorile inevitabile care vor apărea atunci când încercați să efectuați modificări, dar puteți lua măsuri pentru a minimiza apariția erorilor „Declanșare eșuată”, „Conflict de actualizare” sau „Unicitatea cheii încălcate” prin făcând o mică validare înainte de salvare.

Soluția SQL

Cea mai simplă soluție este să utilizați o interogare SQL pentru a verifica tabelul de bază și a vedea dacă noua valoare introdusă există deja. Sunt două puncte de remarcat aici. În primul rând, o interogare SQL se referă întotdeauna la baza de date fizică, deci nu poate fi „confundată” cu ceea ce se află în orice intrare în tampon. În al doilea rând, deoarece SQL se referă întotdeauna la datele de pe disc, va detecta modificările făcute (și salvate) de alți utilizatori. (De fapt, oricum, nu există nicio modalitate de a detecta modificările necommitate ale altor utilizatori - ele pot exista doar în tampoanele de pe computerul unui utilizator.)

Un mare beneficiu al utilizării SQL este că nu mută indicatorul de înregistrare în tabel și, prin urmare, poate fi folosit chiar și atunci când un tabel este stocat pe rând. Iată un exemplu simplu care va verifica dacă un „număr de factură” există deja în tabelul „plăți”:

IcInvNum = ThisForm.txtInvNum.Value

SELECTAȚI număr_factură ;

DIN plăți ;

WHERE număr_factură = lcInvNum ;

Rezultate INTO ARRAY

DACĂ _TALLY > 0

*** Numărul facturii există deja

*** Deci luați măsurile corespunzătoare

ENDIF

Singurul dezavantaj al acestei abordări este că poate fi destul de lent când tabelele sunt foarte mari, cu excepția cazului în care aveți toate câmpurile necesare indexate. Cu toate acestea, așa cum am subliniat deja, prea mulți indici pot cauza alte probleme, în special pe tabele mari.

Alte solutii

Există câteva alternative care nu folosesc SQL și care pot fi mai bune în unele situații. Dacă tabelul are indecșii relevanți, puteți utiliza funcția INDEXSEEK() (introdusă în VFP 6.0). Această funcție va returna o valoare logică în funcție de faptul dacă valoarea specificată există deja în indexul tabelului. Spre deosebire de seeko, comportamentul implicit al indexseeko este de a nu muta indicatorul de înregistrare

înregistrarea potrivită, deși poate fi nevoie de un parametru suplimentar (în a doua poziție) pentru a forța indicatorul de înregistrare să fie mutat atunci când este necesar. Aceasta înseamnă că nu va interfera cu tabelele cu rânduri tampon, deși necesită totuși ca tabelul să fie indexat în câmpul relevant. Aceleași rezultate ca cele ilustrate mai sus ar putea fi obținute folosind INDEXSEEK() astfel:

IcInvNum = ThisForm.txtInvNum.Value

IF INDEXSEEK( 'lcInvNum', .F., 'plati', 'invoice_number' )

*** Numărul facturii există deja

*** Deci luați măsurile corespunzătoare

ENDIF

Există o problemă cu utilizarea INDEXSEEK() cu tabele tamponate. De îndată ce indicatorul de înregistrare este mutat de pe rândul nou adăugat, indexul este actualizat pentru a include noua valoare - chiar dacă tamponarea tabelului este în vigoare. Deci soluția INDEXSEEK() este valabilă numai dacă este aplicată imediat după adăugarea unei noi înregistrări.

O altă alternativă este să utilizați capacitatea Visual FoxPro de a folosi același tabel de mai multe ori și pur și simplu să scanați întregul tabel. În mod surprinzător, Visual FoxPro este foarte bun la acest tip de manipulare, care nu necesită nici un index și este adesea mai rapid decât executarea instrucțiunii SQL echivalente - chiar și atunci când tabelul are indecșii relevanți. Codul este foarte simplu și aceleași rezultate pentru exemplul nostru pot fi obținute cu următoarele câteva linii (care ar putea fi chiar parametrizate și apelate într-o metodă de formular):

IcInvNum = ThisForm.txtInvNum.Value

lnSelect = SELECT ()

UTILIZAȚI DIN NOU plăți PARȚIATĂ ÎN 0 ALIAS schfile NOUPDATE

SELECT schfile

llRetVal = .F.

SCANĂ

IF invoice_number = lcInvnum

llRetVal = .T.

IEȘIRE

ENDIF

ENDSCAN

UTILIZAȚI ÎN schfile

SELECTARE (lnSelect)

RETURN llRetVal
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Utilizarea indecșilor cu tabele legate

Pentru a crea sau șterge o etichetă în indexul structural pentru un tabel care face parte dintr-un DBC (adică unul care este legat) trebuie mai întâi să aveți tabelul deschis exclusiv. Acest lucru poate părea restrictiv, dar are sens în contextul menținerii integrității informațiilor DBC despre tabelele sale. (Această restricție nu se aplică tabelelor sau cursorelor libere, nici creării și modificării fișierelor CDX care nu sunt structurale pentru tabelele legate.) Deci, la prima vedere, s-ar părea că cea mai bună abordare este să indexați tot ceea ce ar putea necesita o index atunci când creați tabele care fac parte dintr-un DBC.

Cu toate acestea, o problemă majoră cu menținerea unui număr mare de etichete de index în indecșii structurali este că actualizarea tabelului poate dura mult timp din cauza necesității de a menține toate etichetele. (Am spus că prea mult este la fel de rău ca prea puțin în contextul indexurilor.) Vă recomandăm, prin urmare, să păstrați numărul de etichete de index de pe tabelele dvs. la minimul absolut necesar în orice moment.

Există, desigur, o problemă aici! Pentru a optimiza interogările (și alte comenzi care folosesc indecși) este posibil să aveți nevoie de mai mulți indecși care sunt utilizați doar rar într-o aplicație. Dacă utilizați tabele libere, puteți pur și simplu să creați indecși temporari și să-i ștergeți după utilizare, dar pentru tabelele legate trebuie să adoptați o strategie diferită.

O opțiune este să utilizați fișiere CDX non-structurale, deoarece nu trebuie să aveți o utilizare exclusivă a tabelului pentru a le crea. Deși acest lucru va funcționa, nu îl recomandăm în general, deoarece astfel de indici trebuie să fie actualizați. Visual FoxPro menține întotdeauna un index structural, dar indecșii nestructurali sunt menținuți doar atâta timp cât sunt deschiși. Cu excepția cazului în care reindexați în mod specific (sau recreați etichetele) la fiecare utilizare, există întotdeauna pericolul ca indexul să nu se mai sincronizeze cu tabelul părinte.

O alternativă de preferat este să folosiți un cursor indexat în loc să accesați direct tabelul legat. Deși acest lucru poate implica mai multă gândire atunci când vine vorba de crearea și popularea cursorului sau actualizarea datelor de bază, se asigură că indicele structural de pe tabelul de bază poate fi păstrat mic. Acest lucru ajută la reducerea supraîncărcării la actualizarea tabelului și evită menținerea sau reconstruirea indicilor nestructurali, ceea ce poate fi lung pentru tabelele mari.
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Cum să indexați tipuri de date mixte atunci când creați o cheie compusă

Trebuie să spunem dinainte că nu ne plac cheile compuse - mai ales când sunt incluse în indexul structural al unui tabel. Cu toate acestea, recunoaștem, de asemenea, că pot exista circumstanțe speciale când o cheie compusă este absolut singurul lucru care vă va permite să vă îndepliniți cerințele. Acest lucru ridică imediat două întrebări.

În primul rând, cum putem crea un index folosind un amestec de tipuri de date? Răspunsul este pur și simplu de a crea o singură cheie concatenată în care fiecare componentă este de același tip de date. În mod normal, aceasta necesită conversia fiecărei componente în echivalentul său de caractere. Deci, pentru a crea un index pe un câmp de caractere și un câmp numeric, expresia index ar fi:

INDEX ON <câmp caracter> + STR( <câmp numeric> ) TAG <nume>

În timp ce echivalentul care implică o dată ar fi:

INDEX PE DTOS( <datafield> ) + <charfield> TAG <nume>

În al doilea rând, cum putem crea un index care implică un element sortat în ordine crescătoare, cu un alt element sortat în ordine descrescătoare? Propozițiile crescătoare/descrescătoare se aplică expresiei în ansamblu, iar în orice expresie index poate fi aplicată în orice caz doar una. Soluția este de a crea o expresie care inversează ordinea naturală pentru elementul care trebuie inversat. De exemplu:

INDEX ON acctref + STR( 10000000 - VAL( SYS( 11, invoicedate )) ) TAG lastinvoice

ar genera un index în care câmpul „”acctref” este în ordine crescătoare, în timp ce câmpul „invoicedate” este în ordine descrescătoare, plasând astfel ultima factură primită pentru fiecare client în fruntea ordinii de sortare. Sys<ii> funcția este folosită aici pentru a converti câmpul de dată într-o zi Julian (în format numeric), care este apoi scăzută dintr-un număr foarte mare pentru a inversa ordinea înainte de a fi convertită într-un șir. După cum vă puteți imagina, acest lucru nu ar fi bine index pentru a crea, sau a menține, pe un tabel mare care are un nivel ridicat de activitate de actualizare și este un caz în care una dintre soluțiile prezentate în secțiunea precedentă ar fi mai aplicabilă!
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Cum se indexează un tabel tamponat

Răspunsul scurt aici este că nu puteți indexa un tabel pentru care Bufferingul tabelului este activat, Visual FoxPro va genera o eroare dacă încercați. Cu toate acestea, dacă nu aveți buffering sau Row buffering, un index poate fi creat în mod obișnuit. Deci tot ceea ce este necesar este să ne asigurăm că toate tabelele sunt forțate la un nivel scăzut de tamponare înainte de indexare sau reindexare.

Singura problemă este că trebuie să vă asigurați că orice modificări în așteptare sunt fie comise, fie revenite înainte de a schimba modul tampon al tabelului. Puteți utiliza funcția cursorgetpropc „buffering” > pentru a returna setarea curentă de buffering pentru un tabel și, dacă rezultatul este fie 4, fie 5 (adică tabelul este tamponat), verificați modificările în așteptare și fie să le commiteți, fie să le anulați după caz. Va fi necesar un astfel de cod:

InOldBuffMode = „buffering” CURSORGETPROPC)

IF InOldBuffMode > 3

*** Ai tabelul Buffering

DACĂ SE MODIFICĂ(O) > 0

*** Există modificări neangajate

*** Gestionează-le aici

ENDIF

ALTE

DACĂ lnOldBuffMode > 1

*** Ai Row Buffering

lcStatus = GETFIELDSTATE( -1 )

DACĂ „2” $ lcStatus SAU „4” $ lcStatus

*** Rândul curent are modificări necommitate

*** Gestionează-le aici

ENDIF

ENDIF

ENDIF

*** Forțare la Buffering pe rând dacă este necesar

DACĂ lnOldBuffMode > 1

CURSORSETPROPC „Buffering”, 3)

ENDIF

*** Acum construiți indici

INDEX PE <orice> TAG <newtag>

*** Restaurare tamponare

CURSORSETPROP( 'Buffering', lnOldBuffMode )

ÎNTOARCERE

Câteva cuvinte de explicație despre indecșii autonomi

În introducerea acestei secțiuni, am afirmat că utilizarea indecșilor autonomi nu se potrivește confortabil cu modelul Visual FoxPro de utilizare a tabelelor și a sesiunilor de date în tampon, dar nu am explicat niciun

mai departe. De fapt, utilizarea fișierelor de sine stătătoare (IDX) (pentru a crea un index temporar, de exemplu) poate provoca unele lucruri foarte ciudate să se întâmple.

Acest lucru se datorează faptului că un fișier IDX este disponibil în toate sesiunile de date, indiferent de locul în care a fost creat. Acest comportament duce la unele rezultate foarte ciudate dacă încercați să utilizați indexul într-o sesiune de date în timp ce tabelul la care se referă este deschis în modul tampon de tabel într-o alta. Vestea bună este că Visual FoxPro va prinde această situație, dar vestea proastă este că o raportează cu numărul de eroare 1579 care afirmă că:

„Comanda nu poate fi emisă pe un tabel cu cursoare în modul de stocare a tabelului”

Acest lucru poate fi deconcertant atunci când comanda este SET INDEX TO <fișier> și tabelul pentru care încercați să setați indexul nu folosește cu siguranță tamponarea tabelului! În plus, dacă utilizați mai multe sesiuni de date și un tabel este deschis folosind tamponarea tabelului în oricare dintre ele, nu puteți crea nici măcar un index autonom pe acel tabel. Veți primi aceeași eroare!

Dacă vă dați seama ce se întâmplă și înșelați forțând buffering-ul fie la niciunul, fie la modul rând în sesiunea de date ofensatoare, creați indexul și setați-l și apoi resetați tamponarea, veți descoperi că nu puteți închide fișierul index fără a obține Eroare #1579.

Nici măcar nu încercați să faceți același lucru în timp ce aveți o tranzacție în vigoare. Dacă reușiți să creați indexul (jucându-vă cu modurile tampon) Visual FoxPro nu vă va permite să închideți tranzacția în timp ce acest index este în uz. Cu toate acestea, veți descoperi că nu puteți închide indexul în timp ce tranzacția este deschisă! A trebuit să repornim Visual FoxPro pentru a ieși din acesta! Concluzia este, prin urmare, să nu faceți parte de indecșii autonomi atunci când utilizați tabele tamponate.
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Lucrul cu containerul bazei de date

Apariția containerului bazei de date în Visual FoxPro 3.0 a oferit unele funcționalități de mult așteptate. Deși păstrează formatul clasic DBF pentru tabele, DBC a adăugat multe caracteristici care sunt standard în sistemele moderne de gestionare a bazelor de date relaționale, dar care trebuiau dezvoltate individual în versiunile anterioare ale FoxPro. DBC oferă suport pentru:

• 	Dicționar de date

• 	Relații persistente

• 	Integritate referenţială încorporată (RI)

• 	Inserați, actualizați și ștergeți declanșatoare pentru tabele

• 	Nume lungi de tabele și reguli de validare a înregistrărilor

• 	Nume lungi de câmpuri și reguli de validare a câmpurilor

• 	Valoare implicită și Comentarii pentru câmpuri

• 	Proprietățile câmpului InputMask și Format

• 	Maparea claselor de control UI la câmpurile de tabel

• 	Conexiuni la surse de date la distanță

• 	Vizualizări locale și de la distanță

Prețul pentru aceasta a fost o modificare a antetului fișierului DBF pentru a include un „backlink” pentru a indica containerul bazei de date în care au fost stocate toate aceste informații. Consecința este că tabelele VFP legate nu pot fi citite de versiunile mai vechi ale FoxPro. Cu toate acestea, dacă nu vă puteți citi tabelele direct atât în VFP, cât și în FP2.x, nu există absolut niciun motiv să nu utilizați containerul bazei de date.

Limitarea este că un tabel poate aparține doar unui container de bază de date la un moment dat. În timp ce Visual FoxPro poate face față cu deschiderea mai multor containere de baze de date, codul pentru a face acest lucru poate deveni dezordonat. Deci, există încă un loc pentru tabelele „gratuite” în Visual FoxPro - în special pentru datele de căutare care sunt partajate între mai multe aplicații - chiar dacă un tabel gratuit nu poate împărtăși beneficiile disponibile pentru verii săi legați.

Folosind nume lungi de tabel

Când creați un tabel care este legat la un container de bază de date, puteți specifica un nume de tabel care este diferit de numele fișierului și poate conține până la 128 de caractere (trebuie să înceapă cu o literă sau un caracter de subliniere!) și poate include spații.

Comportamentul implicit al FoxPro a fost întotdeauna deschiderea unui tabel cu același nume de alias ca numele fișierului, cu excepția cazului în care un alias a fost furnizat în mod explicit. Când tabelele legate sunt deschise, se face o referință înapoi la containerul bazei de date și, dacă a fost specificat un nume de tabel, acesta este folosit ca alias în loc de numele fișierului (deși dacă numele tabelului specificat conține spații - groază! - sunt introduse liniuțe de subliniere). Rezultatul este că puteți defini „Alias-uri” standard pentru tabelele dvs.

Cu toate acestea, deoarece numele lung al tabelului este stocat în containerul bazei de date, eliberarea unui tabel din containerul bazei de date înseamnă că numele său lung va fi pierdut. Rețineți că comanda standard copy to va crea, în mod implicit, un tabel liber și, prin urmare, nu va păstra niciun nume lung de tabel (sau orice altă informație legată de DBC). Pentru a evita acest lucru, trebuie să utilizați întotdeauna clauza de bază de date și să copiați tabelul într-un alt container de bază de date (care trebuie să existe deja, Visual FoxPro nu va crea un nou DBC „din zbor”), astfel:

SELECTează mytable

COPY TO newtable && Creează un tabel GRATUIT, dar pierde informațiile legate de DBC

COPY TO newtable DATABASE newdbc && Copiază tabelul și toate datele în noul DBC

Folosind nume lungi de câmp - nu!

DBC vă permite, de asemenea, să utilizați nume lungi de câmpuri în tabelele dvs. (din nou, până la 128 de caractere). Cu toate acestea, în opinia noastră, acesta nu este un lucru bun! Există un pericol real și prezent în utilizarea numelor lungi de câmpuri, pe lângă dificultatea de a le introduce corect în controale și în cod. Ca și în cazul numelui lung de tabel, datele reale pentru numele lungi de câmp sunt stocate în containerul bazei de date. Limita pentru numele câmpurilor dintr-un tabel liber este exact aceeași ca a fost întotdeauna în FoxPro - 10 caractere. Consecința este că, dacă eliberați un tabel legat care utilizează nume de câmp lungi, numele lung este pierdut și Visual FoxPro înlocuiește un nume de câmp de 10 caractere. Dacă numele câmpurilor scurtate nu sunt unice, FoxPro le face astfel luând primele <n> caractere și adăugând un sufix numeric -astfel:

Nume lung

Nume scurt

THISALONGFIELDNAME

ACEASTA LUNGNUMELE CÂMPULUI ESTE DIFERIT

THISISALON

THISISALO2

Tabelul 7.3 Trunchierea numelor lungi de câmpuri

Acest lucru va rupe codul și este într-adevăr foarte rău - deși este greu de văzut ce altceva poate face Visual FoxPro având în vedere această situație. Deci, puteți spune, pur și simplu nu vom elibera tabele care folosesc nume lungi... .problemă rezolvată.

Din păcate, aceasta nu este singura situație în care numele câmpurilor sunt trunchiate. Cursoarele acceptă nume lungi de câmpuri, astfel încât o selectare SQL dintr-un tabel care le utilizează va păstra numele câmpului intact. Cu toate acestea, dacă apoi doriți să vă păstrați cursorul (facem asta mult când testăm codul care acționează pe tabele mari) și încercați să copiați setul de rezultate într-un tabel temporar - ajungeți cu un tabel liber, cu nume de câmp scurtate și cod care nu va rula. Desigur, puteți crea un alt DBC sau puteți crea tabelul cu un nume nou în DBC existent - dar nicio soluție nu va permite codului dvs. existent să ruleze fără modificare!

Deci credem că întrebarea pe care trebuie să ți-o pui este de ce ai nevoie de nume lungi de câmpuri?

Fiecare câmp dintr-un tabel legat are o proprietate Caption care este utilizată, în mod implicit, în loc de numele câmpului în fiecare loc în care un nume de câmp ar fi afișat în mod normal de Visual FoxPro. Aceasta include în antetul unei grile, ca legendă a etichetei pe care Visual FoxPro o adaugă la controlul casetei de text atunci când trageți un câmp din DE pe un formular și într-o fereastră RAVIGATE. De fapt, singurele locuri în care nu puteți afișa direct proprietatea de lege a unui câmp sunt într-o listă de structură sau când utilizați afieldso (deoarece informațiile sunt în DBC și nu în tabelul în sine).

În orice mediu, legenda câmpului poate fi întotdeauna preluată din DBC (care trebuie să fie disponibil, chiar dacă nu este deja setat ca curent, dacă tabelul este în uz) folosind funcția DBGETPROP(), așa că ni se pare că, deși nume lungi de câmp sunt acceptate, nu există cu adevărat un caz bun pentru a le folosi.

Utilizarea containerelor de baze de date

Când utilizați containerul de baze de date Visual FoxPro, este important să recunoașteți că Visual FoxPro face diferența între un DBC care este doar deschis și DBC care este curent. Majoritatea comenzilor și funcțiilor legate de baze de date funcționează numai pe DBC curent (de ex. DBGETPROP(), DBSETPROP(), ADBOBJECTS() și ihdbco). De asemenea, comanda create se comportă diferit atunci când un DBC este definit ca curent. Tabelul creat va fi adăugat automat la acel DBC, altfel este creat un tabel liber.

Deschiderea unui tabel care este legat de un DBC deschide, de asemenea, (dar nu face curent) DBC asociat, în timp ce deschiderea unui DBC explicit ( OPEN DATABASE <nume> ) face, de asemenea, ca containerul bazei de date curent, dar nu deschide niciunul dintre tabelele sale.

Pentru a face un DBC deschis ca bază de date curentă, trebuie să utilizați comanda SET DATABASE TO <nume>. Baza de date care este curentă rămâne actuală până când este întâlnită o altă comandă OPEN DATABASE sau SET DATABASE TO. Acest lucru permite Visual FoxPro să gestioneze mai multe containere de baze de date simultan, dar

utilizarea mai multor DBC-uri poate face viața dificilă pentru dezvoltator, în special atunci când ambele conțin proceduri stocate, așa cum ilustrează programul ShoStPro.prg:

**************************************************** ********************

* 	Program.ShoStPro.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Ilustrați problemele când utilizați mai multe DBC-uri ************************************* ********************************

*** Deschideți două containere de baze de date

CLAR

DATE DESCHISE bCH07

DATE DESCHISE aCH07

*** Apelați Procs Store

? "DBC curent = " + SET("BAZĂ DE DATE")

DO CheckStProc

*** Acum faceți curent aCH07

SETĂ DATELE LA aCH07

? "DBC curent = " + SET("BAZĂ DE DATE")

DO CheckStProc

*** Acum faceți curent bCH07

SETĂ DATELE LA bCH07

? "DBC curent = " + SET("BAZĂ DE DATE")

DO CheckStProc

*** Acum nu faceți curent DBC

SETARE BAZĂ DE DATE LA

? "DBC curent = " + SET("BAZĂ DE DATE")

DO CheckStProc

INCHIDE TOT

ÎNTOARCERE

PROCEDURĂ CheckStProc

Fă manechin

DO OnlyaCH07

DO OnlybCH07

Dacă rulați acest program din linia de comandă, veți vedea că, cu mai multe DBC-uri deschise, apelarea unei proceduri stocate care există doar într-un singur DBC este bine. Nu contează care DBC este curent, procedura corectă este localizată. Cu toate acestea, dacă ambele DBC-uri conțin o procedură stocată care este numită același, atunci setarea DBC-ului este de o importanță vitală, deoarece Visual FoxPro va căuta întotdeauna mai întâi în baza de date curentă și numai apoi va căuta în orice alte baze de date deschise.

În cele din urmă, dacă NU DBC este definit ca curent, atunci Visual FoxPro execută prima procedură pe care o găsește - în acest exemplu este întotdeauna procedura „fachină” din containerul bazei de date aCH07. Inversarea ordinii în care cele două DBC sunt deschise în programul ShoStPro schimbă rezultatul ultimului test. Acest lucru sugerează că Visual FoxPro menține o colecție internă de baze de date deschise, în care ultima

baza de date care urmează să fie deschisă se află în capul listei și este căutată mai întâi, atunci când nicio bază de date nu este setată ca actuală.

Cum se validează un container de bază de date

Visual FoxPro oferă o comandă VALIDATE DATABASE care va executa o verificare internă a coerenței în baza de date deschisă în prezent. În prezent (Versiunea 6.0a) această comandă poate fi emisă NUMAI din fereastra de comandă și implicit rezultatele sale sunt afișate pe ecranul principal FoxPro. Încercarea de a-l utiliza într-o aplicație provoacă o eroare.

Puteți valida o bază de date fără a obține mai întâi o utilizare exclusivă, dar indexul DBC nu va fi reconstruit și nici nu veți putea remedia erorile pe care le-ar putea găsi procesul. Cu utilizare exclusivă puteți alege fie să reconstruiți indexul (o comandă simplă VALIDATE DATABASE va face exact asta) sau să invocați mecanismul de reparare adăugând clauza „recuperare” la comandă.

Deși nu este foarte sofisticată, opțiunea de recuperare evidențiază cel puțin tot ceea ce VFP consideră că este în neregulă cu DBC-ul dvs. și vă oferă opțiuni fie de a localiza, fie de a șterge un element lipsă și de a șterge sau reconstrui indecșii lipsă (cu condiția ca informațiile necesare să fie disponibile în DBC însuși). Cel mai bun mod de a evita problemele în DBC este să vă asigurați că faceți întotdeauna modificări la tabelele (sau vizualizările) acestuia prin mecanismele proprii ale DBC. Evitați acțiuni precum construirea de indici temporari în afara DBC sau modificarea programatică a definițiilor de vizualizare sau tabel fără a utiliza mai întâi în exclusivitate DBC.

Pe scurt, deși nu este tocmai fragil, DBC se bazează foarte mult pe propria sa consistență internă, iar erorile (reale sau imaginare) îți vor cauza inevitabil probleme mai devreme sau mai târziu.

Cum să împachetați un container de bază de date

Containerul bazei de date Visual FoxPro este, în sine, un tabel normal Visual FoxPro în care fiecare rând conține informațiile stocate pentru un obiect din baza de date. La fel ca toate tabelele Visual FoxPro, ștergerea unei înregistrări marchează doar acea înregistrare pentru ștergere, iar înregistrarea fizică nu este eliminată din DBC. Aceasta înseamnă, în timp, că o bază de date poate deveni mare, chiar dacă de fapt conține foarte puține elemente curente.

Comanda PACK DATABASE este singura metodă pe care ar trebui să o utilizați pentru a curăța un DBC. Pur și simplu deschiderea DBC ca tabel și emiterea unei comenzi PACK standard nu este suficientă deoarece DBC menține un sistem intern de numerotare pentru obiectele sale care nu va fi actualizat decât dacă este utilizată comanda PACK DATABASE. Utilizarea acestei comenzi necesită utilizarea exclusivă a bazei de date.

Mutarea unui container de bază de date

Am menționat mai devreme în această secțiune că singurul preț pentru obținerea tuturor funcționalităților pe care le oferă un container de bază de date este o modificare minoră a antetului tabelului pentru a include un backlink către DBC. Acesta este, într-adevăr, un lucru banal PÂNĂ când încercați să mutați un container de bază de date. Atunci e

semnificaţia poate lua proporţii monstruoase. Motivul este că Visual FoxPro stochează calea relativă de la tabel înapoi la DBC proprietar direct în antetul tabelului. Cu condiția să păstrați întotdeauna DBC și toate tabelele sale de date în același director, totul va fi bine, deoarece tot ceea ce este stocat este numele containerului bazei de date.

Cu toate acestea, atunci când aveți un container de bază de date care NU se află în același director cu tabelele sale, vă expuneți la potențiale probleme. Am creat un tabel în directorul nostru de lucru (C:\VFP60\CH07) și l-am atașat la o bază de date care se afla în directorul C:\TEMP. Backlink-ul adăugat la tabel a fost:

.\TEMP\TESDBC.DBC

După mutarea acestui container al bazei de date în directorul C:\WINDOWS\TEMP, orice încercare de a deschide tabelul a dus la o eroare „nu se poate rezolva backlink” și la opțiunea fie de a localiza DBC-ul lipsă, de a șterge linkul și de a elibera tabelul (cu toate consecințe groaznice pentru numele lungi de câmpuri pe care aceasta le presupune) sau să anuleze. Fiind optimiști, am ales să găsim containerul bazei de date și ni sa oferit un dialog pentru a-l găsi. Din păcate, după ce am găsit DBC-ul nostru și l-am selectat, ne-am confruntat imediat cu eroarea 110 care ne informa că „Fișierul trebuie deschis exclusiv” Nu este foarte util!

Remedierea backlink-ului pentru o masă

Deci ce se poate face? Din fericire, structura antetului DBF este listată în fișierul Ajutor (consultați subiectul „Table File Structure” pentru mai multe detalii), iar Visual FoxPro ne oferă câteva funcții de gestionare a fișierelor de nivel scăzut, care ne permit să deschidem un fișier și să citim și să scriem. la el la nivel de octet. Deci putem scrie în noua locație pentru DBC și totul va fi bine. Singura întrebare este unde să scriu?

Veți vedea din fișierul Ajutor că dimensiunea antetului tabelului este de fapt determinată de formula:

32 + (nFields * 32) +264 bytes

Unde nFields este numărul de câmpuri din tabel, pe care le-am putea obține folosind fcounto - dacă am putea deschide tabelul! (Există și un headero - o mică funcție utilă care ne spune de fapt cât de mare este antetul mesei. Din păcate, necesită și să putem deschide masa.) Dar dacă am putea deschide masa, nu ar fi nevoie să o deschidem. remediați și backlink-ul.

Backlink-ul în sine este păstrat ca ultimii 263 de octeți ai antetului tabelului. Cu toate acestea, singura modalitate sigură de a obține acești 263 de octeți vitali este să încercați să citiți numărul maxim posibil de octeți care ar putea fi vreodată într-un antet de tabel. (Încercarea de a citi dincolo de sfârșitul fișierului nu generează o eroare la o citire de nivel scăzut, ci doar se oprește la sfârșitul marcatorului de fișier.) Visual FoxPro este limitat la 255 de câmpuri per înregistrare, așa că trebuie, folosind formula de mai sus, să citit în 8.456 octeți. Aceasta se încadrează bine în noua limită superioară de 16.777.184 de caractere per șir de caractere sau variabilă de memorie, așa că totul este bine.

Din fericire, secțiunea de înregistrări de câmp din antet se termină întotdeauna cu un șir de 13 „nuli”. caractere (caracterul ASCII 0) urmate de „Returul carușului” (caracterul ASCII 13). Deci, dacă găsim acest șir în blocul pe care l-am citit din tabel, vom avea începutul backlink-ului. Următoarea funcție folosește această tehnică pentru a citi informațiile backlink dintr-un tabel (când este transmis doar numele fișierului tabelului) sau pentru a scrie un șir de backlink nou (transmite atât numele fișierului, cât și noul backlink):

**************************************************** ********************

* 	Program. BackLink.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Setează/Returnează informații de backlink dintr-un tabel

* 	..........:Trimiteți ambele nume de fișier DBF (inclusiv extensia) numai către

* 	..........:pentru a returna backlink, transmiteți și un nou șir de backlink către

* 	..........:scrieți un nou backlink

**************************************************** ********************

LPARAMETERS tcTable, tcDBCPath

LOCAL lnParms, lnHnd, lnHdrStart, lnHdrSize, lcBackLink, lcNewLink lnParms = PCOUNT()

*** Verificați dacă fișierul există

DACĂ ! FIȘIER (tcTable)

EROARE „9000: Nu se poate localiza fișierul” + tcTable

RETURNARE .F.

ENDIF

*** Deschideți fișierul la nivel scăzut - Numai citire dacă citiți doar informații

lnHnd = FOPEN( tcTable, IIF( lnParms > 1, 2, 0) )

*** Verificați fișierul este deschis

DACĂ lnHnd > 0

*** Backlink este ultimii 263 de octeți ai antetului, așa că calculați poziția

*** Dimensiunea maximă a antetului este (32 + ( 255 * 32 ) + 264) = 8456 octeți

lcStr = FREAD( lnHnd, 8456 )

*** Înregistrările câmpului se termină cu 13 NULLS + „CR”

lcFieldEnd = REPLICATE( CHR(0), 13 ) + CHR(13)

lnHeaderStart = AT( lcFieldEnd, lcStr ) + 13

*** Mutați indicatorul fișierului în poziția de început a antetului

FSEEK( lnHnd, lnHeaderStart )

*** Citiți backlink

lcBackLink = UPPER( ALLTRIM( STRTRAN( FGETS( lnHnd, 263 ), CHR(0) ) ) )

*** Dacă scriem un nou backlink

DACA lnParms > 1

*** Obțineți calea (maximum 263 de caractere!)

tcDBCPath = LEFT(tcDBCPath,263)

*** Întindeți-o pe toată lungimea cu NULLS

lcNewLink = PADR( ALLTRIM( LOWER( tcDBCPath ) ), 263, CHR(0) )

*** Accesați începutul Backlink

FSEEK( lnHnd, lnHeaderStart )

*** Scrieți noile informații de backlink

FWRITE( lnHnd, lcNewLink )

*** Setați noul backlink ca valoare de returnare

lcBackLink = tcDbcPath

ENDIF

*** Închideți fișierul

FCLOSE(lnHnd)

ALTE

EROARE „9000: Nu se poate deschide fișierul tabelului”

lcBackLink

ENDIF

*** Returnați backlink-ul

RETURN lcBackLink

Ce se întâmplă cu vizualizările când mut containerul bazei de date?

Vestea bună este că mutarea unui container de bază de date nu are niciun efect asupra vizualizărilor. Vizualizările sunt stocate ca instrucțiuni SQL în interiorul containerului bazei de date și, deși fac referire la DBC după nume, ele nu dețin informații despre cale. Deci nu este nevoie să vă faceți griji în privința lor dacă mutați un DBC dintr-o locație în alta (pf!).

Redenumirea unui container de bază de date

Redenumirea unui container de bază de date prezintă un set diferit de probleme. De data aceasta, atât tabelele, cât și vizualizările sunt afectate. Tabelele vor fi afectate din cauza backlink-ului pe care îl dețin - care va sfârși prin a indica ceva care nu mai există. Cu toate acestea, acest lucru este relativ ușor de remediat, așa cum am văzut deja, și poate fi ușor automatizat. În acest caz, totuși, Vizualizările vor fi afectate deoarece Visual FoxPro include foarte util numele DBC ca parte a interogării care este stocată. Iată o parte din rezultatul pentru o interogare (generată de utilitarul GENDBC.PRG care este livrat cu Visual FoxPro și care poate fi găsit în subdirectorul VFP\Tools):

FUNCȚIA MakeView_TESTVIEW

***************** Vizualizați configurarea pentru TESTVIEW ***************

CREATE SQL VIEW "TESTVIEW" ;

AS SELECT Optutil.config, Optutil.type, Optutil.classname FROM testdbc!optutil

DBSetProp('TESTVIEW', 'Vizualizare', 'Tabele', 'testdbc!optutil')

* 	Props pentru câmpul TESTVIEW.config.

DBSetProp('TESTVIEW.config', 'Field', 'KeyField', .T.)

DBSetProp('TESTVIEW.config', 'Field', 'Updatable', .F.)

DBSetProp('TESTVIEW.config', 'Field', 'UpdateName', 'testdbc!optutil.config')

DBSetProp('TESTVIEW.config', 'Field', 'DataType', "C(20)")

* 	Recuzită pentru câmpul TESTVIEW.type.

DBSetProp('TESTVIEW.type', 'Field', 'UpdateName', 'testdbc!optutil.type')

* 	Props pentru câmpul TESTVIEW.classname.

DBSetProp('TESTVIEW.classname', 'Field', 'UpdateName', 'testdbc!optutil.classname')

ENDFUNC

Observați că containerul bazei de date este adăugat înaintea numelui tabelului de fiecare dată - nu doar în linia de selectare reală, ci și ca parte a proprietății „updatename” a fiecărui câmp. Acest lucru este, fără îndoială, foarte util atunci când lucrați cu mai multe containere de baze de date, dar este o durere regală atunci când trebuie să redenumiți singurul DBC. Din păcate, nu am reușit să găsim o soluție bună la această problemă. Singurul lucru pe care îl putem sugera este că, dacă utilizați Views, ar trebui să evitați redenumirea DBC dacă este posibil.

Dacă trebuie neapărat să redenumiți DBC, atunci cea mai sigură soluție este să rulați GENDBC.PRG înainte de a-l redenumi și să extrageți toate definițiile vizualizării într-un fișier de program separat pe care să îl puteți edita apoi

actualizați toate aparițiile vechiului nume cu noul. Odată ce ați redenumit DBC, pur și simplu ștergeți toate vizualizările și rulați programul editat pentru a le re-crea în noua bază de date redenumită.

Notă: Codul SQL pentru a genera o vizualizare este stocat în câmpul „proprietăți” al fiecărei înregistrări „Vizualizare” din containerul bazei de date. Deși este stocat ca cod obiect, numele câmpurilor și tabelelor sunt vizibile ca text simplu. Am văzut sugestii care implică piratarea directă a acestui câmp de proprietăți pentru a înlocui numele DBC, dar nu putem susține această practică! În testarea noastră s-a dovedit a fi o metodă complet nesigură, care de cele mai multe ori a făcut vizualizarea atât inutilizabilă, cât și imposibil de editat. Utilizarea GENDBC poate fi mai puțin plină de farmec, dar este mult mai sigură!
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Gestionarea integrității referențiale în Visual FoxPro

Termenul „integritate referențială”, de obicei abreviat la „RT”, înseamnă asigurarea faptului că înregistrările conținute în tabelele aferente sunt consecvente. Cu alte cuvinte, fiecare înregistrare copil (la orice nivel) are un părinte corespunzător și că orice acțiune care modifică valoarea cheie folosită pentru a identifica un părinte se reflectă în toți copiii acestuia. Obiectivul este de a se asigura că înregistrările „orfane” nu pot intra niciodată într-un tabel sau nu pot fi lăsate pe loc într-un tabel.

Visual FoxPro a introdus regulile RI încorporate în versiunea 3.0. Acestea sunt implementate prin utilizarea relațiilor persistente dintre tabele definite în containerul bazei de date și a declanșatorilor de pe tabele pentru a se asigura că modificările valorilor cheie din tabele sunt gestionate conform regulilor pe care le definiți . Generatorul RI standard permite trei tipuri de reguli, după cum urmează:

• 	Ignorare: setarea implicită pentru toate acțiunile, nu este aplicat niciun RI și orice actualizare a oricărui tabel poate continua - exact ca în versiunile anterioare ale FoxPro

• 	Cascade: modificările aduse valorii cheii din tabelul părinte sunt reflectate automat în cheile străine corespunzătoare din toate tabelele secundare pentru a menține relațiile

• 	Restricționați: modificările care ar duce la o încălcare a RI sunt interzise

Configurarea RI în Visual FoxPro este destul de simplă, iar generatorul RI se ocupă de toată munca pentru dvs. Figura 7.3, de mai jos, arată configurarea în curs pentru o structură relațională simplă care implică patru tabele (Am folosit tabelele din baza de date VFP Samples „TestData” pentru a ilustra această secțiune). Până acum au fost stabilite următoarele reguli:

Tabelul 7.4 Configurarea tipică a regulilor RI

Tabel părinte 	Child TableActionRule
Comenzile cliențilorInsertIgnore	
Comenzile cliențilorUpdateCascade	
Comenzile cliențilorDeleteRestrict	
Comenzi 	OrdItemsInsertRestrict
Comenzi 	OrdItemsUpdateCascade

Comenzi

Ordltems

Șterge

Restricționați

Consecințele acestor reguli sunt că un utilizator poate adăuga oricând un nou client (Ignorați clientul Inserí), dar nu poate șterge un client care are comenzi pe fde (Restricționați ștergerea clientului) și orice modificare a cheii unui client va actualiza cheile de comandă corespunzătoare ( Actualizare Cascade pentru clienți). Pentru tabelul de comenzi, regulile sunt că un articol de comandă poate fi inserat numai într-o comandă validă (Restrict Order Inserì), că nicio comandă nu poate fi ștearsă în timp ce are articole asociate (Restrict Order Delete) și că orice modificare a unei comenzi valoarea cheie se va reflecta în toate articolele la care se referă (Actualizarea comenzii în cascadă).

Figura 7.3 Utilizarea constructorului VFP RI

Limitări ale codului generator RI

Din păcate, implementarea în Visual FoxPro nu este foarte eficientă - generarea de reguli RI pentru o mulțime de tabele are ca rezultat adăugarea unei cantități enorme de cod procedural clasic „stil xBase” la procedurile stocate din containerul bazei de date. Regulile definite în exemplul de mai sus au rezultat în 636 de linii de cod în 12 proceduri separate. Fiecare tabel are propria sa procedură numită pentru fiecare declanșator generat - astfel, în exemplul de mai sus, procedurile sunt generate denumite:

PROCEDURA __RI_DELETE_CUStomer

PROCEDURA __Rl_DELETE_comenzi

PROCEDURA RI INSERT ordltems

procedura __RI_UPDATE_client

procedura __RI_UPDATE_comenzi

procedura ___RI_UPDATE_orditems

(Rețineți inconsecvența în scrierea cu majuscule a cuvântului cheie „PROCEDURE”!) Adăugarea mai multor tabele și mai multe reguli crește cantitatea de cod. În plus, acest cod nu este bine comentat și, în versiunile timpurii, conținea mai multe erori care l-ar putea face să eșueze în anumite condiții - dintre care cel puțin unul a persistat până în cea mai recentă versiune a Visual FoxPro.

Următorul cod este preluat direct din procedurile stocate generate de VFP V6.0 (Build 8492) pentru exemplul prezentat mai sus:

procedura RIDELETE

local llRetVal

llRetVal=.t.

IF (ISRLOCKED() și !deleted()) SAU !RLOCK()

llRetVal=.F.

ALTE

DACA !sters()

ȘTERGE

DACĂ CURSORGETPROP(„BUFFERING”) > 1

=TABLEUPDATE()

ENDIF

llRetVal=pnerror=0

ENDIF nu a fost deja șters

ENDIF

DEBLOCARE ÎNREGISTRARE (RECNO())

RETURN llRetVal

Veți observa că linia de cod cu italice este plasată incorect și ar trebui să fie în afara blocului if !DELETED(). Așa cum este, valoarea returnată din acest cod poate fi incorectă (în funcție de valoarea „pnerror” la momentul respectiv) dacă înregistrarea care este testată este deja marcată pentru ștergere.

În afară de acest bug specific și în ciuda criticilor aduse mecanismului de generare a codului RI, codul funcționează de fapt bine atunci când este utilizat cu tabele care sunt structurate în modul în care era de așteptat. Cu siguranță este mai ușor să folosești generatorul RI decât să încerci să scrii propriul tău cod! Există, totuși, o atenție suplimentară de avut în vedere atunci când utilizați generatorul RI.

Utilizarea cheilor compuse în relații

La generarea codului RI pentru tabelele din exemplu, a fost afișat acest avertisment:

Figura 7.4 Atenție!

Ce naiba înseamnă asta? În mod clar, este o serie care se așteaptă sau Visual FoxPro nu l-ar genera! Răspunsul este că indexul obișnuit folosit ca țintă pentru relația persistentă dintre tabelul Comenzi și Articole comanda se bazează de fapt pe o cheie compusă care cuprinde cheia externă a tabelului Comenzi plus Numărul articolului. Expresia de index în cauză este cea folosită pe orditems tabelului copil, care este de fapt " order_id+STR(line_no, 5,0) ". (Acest lucru a fost configurat astfel încât atunci când elementele sunt afișate, acestea vor apărea în ordinea numărului de rând. Nu este chiar un lucru nerezonabil de făcut!) Cu toate acestea, orice încercare de a introduce sau de a schimba o înregistrare în tabelul copil (orditems), va provoca un „Trigger”. Eroare eșuată.

Problema este că orice regulă configurată pe acest tabel care trebuie să se refere la tabelul părinte va folosi, ca cheie pentru seeko, valorile câmpurilor concatenate din tabelul copil. Acest lucru, evident, va eșua întotdeauna, deoarece cheia pentru tabelul părinte Çorders *) este doar prima parte a cheii concatenate în copil. După cum spune mesajul, puteți (destul de ușor) să editați codul generat, astfel încât valoarea cheie corectă să fie utilizată în aceste situații.

Următorul extras arată problema:

PROCEDURA RI_UPDATE_or di teins

*** Alt cod aici ***

*** Apoi obținem valorile vechi și noi pentru tabelul copil

SELECTARE (IcChildWkArea)

*** Aici apare eroarea!! !

lcChildID=ORDER_ID+STR(LINE_NO,5,0) lc01dChildID=oldval("ORDER_ID+STR(LINE_NO,5,0)") *** Alt cod aici ***

*** daca valorile s-au schimbat, avem o problema!! !

IF IcChildIDOlcOldChildlD

pcParentDBF=dbf(IcParentWkArea)

*** Și aici este locul în care totul merge prost

HRetVal=SEEK (IcChildlD, IcParen tWkArea)

*** Și aici este generată eroarea reală

DACĂ NU llRetVal

DO rierror cu -l,"Insert restrict rule a încălcat.

DACĂ _triggerlevel=1

DO riend CU llRetVal

ENDIF la sfârșitul celui mai înalt nivel de declanșare

ENDIF această valoare a fost modificată

Deoarece cheia pentru ID-ul copilului este codificată în format hard atunci când este generat codul RI, editarea efectivă necesară este foarte simplă - doar ștergeți concatenarea. Din păcate, modificările dvs. vor fi valabile atâta timp cât nu regenerați codul RI.

Adevăratul răspuns la această problemă este însă foarte simplu. Doar nu o face! După cum am sugerat deja, cheile surogat ar trebui să fie întotdeauna folosite pentru a lega tabele, astfel încât să aveți o metodă clară de a uni două tabele împreună. În plus față de celelalte virtuți ale lor, ele se asigură, de asemenea, că nu trebuie să utilizați niciodată chei compuse pentru a aplica RI.

Dar alte opțiuni RI?

Constructorul nativ gestionează doar trei alternative posibile atunci când impune RI - Cascade, Restrict și Delete - și presupune că înregistrările „orfane” sunt întotdeauna un „lucru rău”. În practică, acest lucru nu este neapărat cazul (cu condiția să proiectați pentru acea situație!) și există cel puțin un caz în care o opțiune „Adoptare” ar fi utilă. Luați în considerare situația în care un vânzător, care este responsabil pentru un grup de clienți și, prin urmare, pentru comenzile acestora, părăsește compania. Desigur, trebuie să indicăm că acel ID de vânzător nu mai este valabil ca vânzător responsabil pentru acești clienți și trebuie să desemnăm o nouă persoană. Dar cum rămâne cu comenzile pe care vânzătorul le-a luat în timp ce lucra pentru companie?

Dacă pur și simplu ștergem vânzătorul, o regulă „Restricționare” a RI ar interzice ștergerea, deoarece există înregistrări „copil” pentru acea cheie. Ceea ce este cu adevărat nevoie este o variantă a regulii de ștergere care spune:

„Dacă înregistrarea părinte este ștearsă și este furnizată o cheie validă, atribuiți toate înregistrările copil existente la cheia specificată.”

Acest lucru nu este încă disponibil în Visual FoxPro, dar un declanșator care impune o astfel de regulă ar fi destul de ușor de creat, pseudocodul este pur și simplu:

Verificați dacă există înregistrări care să facă referire la cheia care urmează să fie ștearsă

Dacă nu există, permiteți ștergerea și ieșiți

Dacă a fost specificată o cheie nouă, validă

Schimbați toate înregistrările copil existente la noua cheie

Ștergeți înregistrarea originală a părintelui

Ieșire

Doriți mai multe detalii despre RI?

Pentru mai multe detalii despre subiectul RI în Visual FoxPro și un exemplu de alternativă completă bazată pe SQL la codul RI nativ, nu putem face mai bine decât să vă referim la capitolul 6 din excelentul „Tehnici eficiente pentru dezvoltarea aplicațiilor cu Visual FoxPro 6.0”, de Jim Booth și Steve Sawyer (Hentzenwerke Publishing, 1998).
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Utilizarea declanșatoarelor și a regulilor în Visual FoxPro

Mai întâi avem nevoie de niște definiții. Declanșatoarele și regulile pot fi implementate numai pentru tabelele care fac parte dintr-un container de baze de date, pentru a permite dezvoltatorului să gestioneze problemele legate de integritatea datelor. Declanșatoarele se declanșează numai atunci când datele sunt de fapt scrise în tabelul fizic - deci nu pot fi utilizate pentru verificarea valorilor, deoarece sunt introduse într-un tabel tamponat. Există de fapt două seturi de reguli disponibile - Reguli de câmp și reguli de masă. Atât regulile la nivel de câmp, cât și la nivel de tabel (sau mai precis, „Nivelul rândului!)” pot face referire sau modifica orice câmp individual sau combinație de câmpuri din rândul curent. Regulile sunt declanșate ori de câte ori obiectul la care se referă își pierde focalizarea - indiferent dacă tabelul este sau nu în buffer - și astfel pot fi utilizate pentru validarea datelor pe măsură ce sunt introduse.

Deci, care este diferența practică dintre un „declanșator” și o „regulă”?

Un declanșator, așa cum este implementat în Visual FoxPro, este un test care este aplicat ori de câte ori baza de date detectează o modificare scrisă într-unul dintre tabelele sale. Există, așadar, trei tipuri de declanșatoare - câte unul pentru fiecare dintre tipurile de modificări care pot apărea (Insert, Update și Delete). Esența unui declanșator este că expresia care îl apelează trebuie să returneze o valoare logică care să indice dacă modificarea ar trebui să fie permisă să continue sau nu. Acest lucru este cel mai simplu dacă declanșatorul în sine returnează întotdeauna o valoare logică, deci dacă un declanșator returnează o valoare de .f. apare o eroare (Eroarea #1539 - „Trigger Failed”) și modificarea nu este trimisă în tabelul de bază. Declanșatoarele nu pot fi utilizate pentru a modifica valorile din înregistrarea care le-a determinat să se declanșeze, dar pot fi folosite pentru a face modificări în alte tabele. O utilizare foarte comună a declanșatorilor este, prin urmare, pentru crearea jurnalelor de audit! (Apropo, dacă vă întrebați de ce există această restricție, luați în considerare ce s-ar întâmpla dacă ați putea schimba rândul curent din codul care a fost apelat ori de câte ori au fost detectate modificări în rândul curent!).

La fel ca declanșatoarele, apelurile la reguli trebuie să returneze și o valoare logică; dar spre deosebire de declanșatori, aceștia pot aduce modificări datelor din rândul la care se referă. De asemenea, deoarece se declanșează pentru tabelele tamponate, regulile pot fi folosite pentru a efectua validarea direct în interfața de utilizare a unei aplicații, evitând astfel necesitatea scrierii codului direct în interfață. O regulă poate fi, de asemenea, utilizată pentru a modifica câmpuri care nu fac parte din interfața de utilizare (de exemplu, o dată „ultimei modificări” sau un câmp ID utilizator). În practică, singura diferență dintre regulile de câmp și de masă este atunci când sunt declanșate.

Atât declanșatorii, cât și regulile se aplică (ca orice altă procedură stocată) indiferent dacă tabelul în cauză este deschis într-o aplicație sau doar într-o fereastră de navigare. Diferențele dintre declanșatoare și reguli pot fi rezumate astfel:

Tabelul 7.5 Diferențele dintre declanșatoare și reguli

Element 	FiresCapability
		

Regulă de câmp 	Când câmpul pierde focalizarea Poate face referire sau modifica orice câmp din înregistrare
Regula tabelului 	Când indicatorul înregistrării se mișcă Poate face referire sau modifica orice câmp din înregistrare
Declanșare 	Când datele sunt salvate pe disc. Nu se pot modifica datele din înregistrarea care a declanșat declanșatorul

De ce, atunci când adăugați un declanșator la un tabel, VFP îl respinge uneori?

În mod normal, acest lucru indică faptul că datele pe care le aveți în tabelul dvs. sunt deja în conflict cu regula pe care încercați să o aplicați. (Veți vedea uneori o problemă similară când încercați să adăugați un index candidat la un tabel populat.) Când modificați un tabel la adăugați un declanșator sau o regulă, Visual FoxPro aplică acel test tuturor înregistrărilor existente - dacă datele dintr-o înregistrare existentă nu respectă regula, atunci veți primi această eroare. Singura soluție este să corectați datele înainte de a aplica din nou regula.

Verificați cu atenție logica regulilor dvs

Un alt motiv posibil pentru erori la aplicarea regulilor sau a declanșatorilor este logica defectuoasă din partea dezvoltatorului. Trebuie să fiți atenți când definiți reguli pentru a vă asigura că nu aruncați din greșeală Visual FoxPro într-o buclă nesfârșită. Acest lucru se poate întâmpla cu ușurință atunci când utilizați o regulă pentru a modifica datele, deoarece modificarea face ca aceeași regulă să se declanșeze din nou. De exemplu, următoarea regulă de câmp va provoca o eroare „Efectuați nivelul de imbricare”:

DACĂ !EMPTY(ALLTRIM (climpy)) ȘI NU ALLTRIM(PROPER(clicnpy))== ALLTRIM(climpy)

*** Forțați formatul la majuscule! (Aceasta este o regula aiurea!)

ÎNLOCUIȚI clicmpy CU SUS (climpy)

ENDIF

Motivul este că pur și simplu nu poate reuși niciodată! Testul afirmă de fapt că, dacă câmpul nu este în format propero, schimbați-l în uppero . Prin urmare, prima dată când această regulă se declanșează, Visual FoxPro este blocat într-o buclă nesfârșită în care constată că câmpul este în format greșit. Apoi schimbă formatul într-un alt format care declanșează din nou regula, dar câmpul este încă în format greșit, așa că îl schimbă din nou ... și așa mai departe adinfinitum! Următoarea regulă VA funcționa conform așteptărilor:

DACĂ !EMPTY(ALLTRIM (climpy)) ȘI NU ALLTRIM(PROPER(climpy)) = ALLTRIM(climpy)

*** Forțați formatul la majuscule PROPER

ÎNLOCUIRE clicmpy CU PROPER(climpy)

ENDIF

Pot dezactiva temporar un declanșator sau o regulă atunci?

Cu siguranță. Cel mai simplu mod de a face acest lucru este să includeți un test pentru un indicator la nivel de aplicație, (adică fie o variabilă care este „publică” pentru aplicație, fie o proprietate pe un obiect de aplicație) în codul pe care declanșatorul sau regula îl implementează. Vă sugerăm să utilizați o variabilă, deoarece este posibil să doriți să faceți acest lucru în afara unei aplicații și este mai ușor să creați o variabilă publică din linia de comandă decât să trebuiască să instanțiați obiectul aplicației de fiecare dată când doriți să utilizați un tabel. Următorul cod, plasat în procedura stocată și apelat de un declanșator va returna pur și simplu o valoare de .t. când variabila specificată nu este găsită:

IF VARTYPE( glDisableRules ) = "L" AND ! EMPTY( glDisableRules )

RETURNARE .T.

ENDIF

O întrebare pe care s-ar putea să ți-o pui este de ce ar vrea cineva să dezactiveze declanșatoarele sau regulile - după ce s-a chinuit să le configureze? Este posibil ca dacă efectuați o încărcare de date în bloc sau o înlocuire de bloc, penalizarea validării fiecărui rând în mod individual ar încetini prea mult lucrurile - mai ales când modificările au fost deja prevalidate înainte de a fi aplicate. Dacă aceasta este o caracteristică a aplicației dvs., poate fi de fapt mai bine să adăugați o procedură stocată separată pentru a testa dacă regulile ar trebui aplicate sau nu și să o apelați de la fiecare declanșator sau regulă. Prin urmare:

FUNCȚIE ApplyRules

LOCAL llRetVal

MAGAZIN .T. TO llRetVal

*** Test pentru prezența variabilei de dezactivare

IF VARTYPE( glDisableRules ) = "L" AND ! EMPTY( glDisableRules )

llRetVal = .F.

ENDIF

RETURN llRetVal

Fiecare declanșare sau funcție de regulă ar începe apoi:

FUNCȚIE SomeTrigger

DACĂ ! Aplicare reguli()

RETURNARE .T.

ENDIF

*** Cod de declanșare real aici

Este imperativ ca declanșatoarele și regulile dvs. să returneze un .T logic. când codul lor nu este

în curs de executare, altfel va fi generată o eroare „Trigger Failed”.

Cum îmi creez de fapt procedurile de declanșare și reguli?

Codul real, presupunând că aveți nevoie de mai mult decât o simplă regulă cu o singură linie, pentru declanșatoare și reguli este cel mai bine stocat în containerul bazei de date ca o procedură stocată. Aceasta nu este o cerință absolută, deoarece Visual FoxPro ar găsi o procedură chiar dacă nu ar fi în containerul bazei de date (cu condiția ca fișierul necesar să fi fost stabilit cu o comandă „Set Procedure To”). Cu toate acestea, deoarece procedura ar putea fi necesară în orice moment, tabelul care o apelează este utilizat, este mai logic să o lăsați în containerul bazei de date, astfel încât să fie disponibilă oricând și, totuși, tabelul este utilizat.

Deci întrebarea rămâne - cum creați codul real? Există (ca de obicei în Visual FoxPro) două opțiuni. Puteți face acest lucru interactiv folosind fie opțiunea Edit StoredProcedures atunci când modificați baza de date, fie pur și simplu lansând MODIFICARE PROCEDURI din fereastra de comandă. Puteți, de asemenea, să scrieți (și să testați!) codul într-un fișier de program autonom și să îl adăugați la procedurile stocate în mod programatic utilizând APPEND PROCEDURES FROM <filename>. În orice caz, mai întâi trebuie să fi deschis și actualizat baza de date relevantă.

Am înțeles comanda Append Procedures

Există un lucru de reținut atunci când utilizați comanda Adăugare proceduri. Comentariile fișierului Ajutor la această comandă sunt literalmente exacte în ceea ce privește ceea ce face de fapt clauza OVERWRITE pentru această comandă. Fișierul de ajutor afirmă că clauza OVERWRITE:

Specifică faptul că procedurile curente stocate în baza de date sunt suprascrise de cele din fișierul text.

Aceasta NU înseamnă că „orice procedură cu același nume va fi suprascrisă”, înseamnă exact ce scrie. TOATE procedurile aflate în prezent în containerul bazei de date sunt șterse și înlocuite cu orice se află în fișierul sursă pe care îl specificați. Vă recomandăm insistent să trimiteți clauza OverWrite a acestei comenzi în coșul de gunoi chiar acum.

Dar dacă actualizez o procedură fără „suprascriere”, asta nu înseamnă că ajung cu două?

Intr-adevar da. Dacă aveți deja o procedură în containerul bazei de date numită mytestproc' și apoi adăugați o nouă versiune a aceleiași proceduri, veți avea două proceduri numite 'mytestproc' în containerul bazei de date. Din fericire, procedura nou atașată va fi la sfârșitul fișierului și, astfel, va fi întotdeauna versiunea pe care VFP o compilează și o folosește. Deși poate părea dezordonat, va funcționa corect. Cu toate acestea, nu ar trebui să lăsați containerul bazei de date în această stare și, cât mai curând posibil, ar trebui să obțineți acces la el și să ștergeți orice proceduri redundante.

O abordare alternativă este de a menține întotdeauna procedurile stocate ca un set complet de proceduri de înlocuire într-un fișier extern și apoi de a folosi clauza OverWrite a procedurilor de anexare pentru a forța înlocuirea totală a tuturor procedurilor. Dacă practicați controlul etanș al versiunii, vă puteți simți suficient de încrezător pentru a face acest lucru într-o aplicație care funcționează. (În acest caz, pentru a-l parafraza pe Rudyard Kipling, „Ești un bărbat mai curajos decât mine, Gunga-Din”.)

Cum adaug un declanșator la un tabel?

Ca și în cazul codului din procedura de declanșare, acest lucru se poate face fie interactiv în designerul de tabel prin inserarea expresiei corespunzătoare în fila „Tabel” a casetei de dialog, fie programatic folosind comanda CREATE TRIGGER. Amintiți-vă că expresia de apelare trebuie să fie evaluată la o valoare logică și este de preferat ca un apel către o procedură stocată să returneze o valoare logică. În orice caz, veți avea nevoie de acces exclusiv la masă.

Deci, când ar trebui să folosesc un declanșator?

Răspunsul, ca întotdeauna, este că depinde de cerințele tale. Declanșatorii sunt utilizați în mod normal pentru oricare dintre două motive (și uneori ambele). În primul rând, pentru a menține integritatea referențială (RI) - și acesta este modul în care Visual FoxPro implementează codul generat de constructorul RI. În al doilea rând, pentru a crea trasee de audit prin urmărirea modificărilor la un tabel. Amintiți-vă că un declanșator se declanșează numai atunci când se fac modificări la un tabel fizic și, prin urmare, nu are nicio relevanță atunci când lucrați cu date stocate în tampon.

Este demn de remarcat faptul că, în cadrul unui declanșator, nu se aplică restricția conform căreia funcțiile GetFldState() și OldVal () pot fi utilizate numai pe tabele care au activată tamponarea. Ambele funcții vor funcționa fără eroare, chiar și pe tabele fără tampon, ceea ce este extrem de util atunci când se creează trasee de audit în interiorul declanșatorilor.

Un exemplu de lucru folosind declanșatoare

Exemplul de cod pentru acest capitol include o mică bază de date ÇAuditlog') și un formular simplu

(„FrmAudit”) care ilustrează modul în care declanșatorii pot fi utilizați pentru a construi un jurnal de audit. Formularul poate fi rulat autonom direct din linia de comandă folosind comanda do form. Tabelele au fost construite după cum urmează (câmpurile prefixate cu „#” sunt cheile primare):

Tabel STOCK

ttSTOSID STODESC

30

STOCOST

STOQTY

ST OVAL UE

10,2

4

10,2

Tabel HEADER AUDIT 		DETALII AUDIT Tabel
#LHDRSID I 4 		#LITHSID I 4
LHDRTABL CS 		LHDRKEY I 4
LHDRTYPE C fi 		LITMELD C 30
LHDRDATE TS 		LITtlFuAL C 30
LHDRUSER CS 		LITMTUAL C 30 LITMTYPE C 1

eu

c

H

H

Figura 7.5 Tabelele de înregistrare a auditului

Declanșatoarele de pe tabelul „Stoc” adaugă date la tabelele de audit ori de câte ori este efectuată o modificare, cu toate acestea, numai articolele care sunt modificate efectiv sunt scrise în timpul unei actualizări (toate articolele sunt, prin definiție, modificate atunci când se efectuează fie o inserare, fie o ștergere). Alte proceduri stocate sunt utilizate pentru a implementa o funcție standard „newid” pentru generarea cheilor primare și, de asemenea, pentru a implementa o regulă de câmp pentru calcularea valorii unui articol de stoc atunci când sunt furnizate atât o cantitate, cât și un cost.

Funcționalitatea de înregistrare a auditului este gestionată de funcția „BildLog” formată din trei părți. În primul rând, deoarece funcția va folosi o tranzacție, se asigură că toate tabelele suport (inclusiv tabelul de generare PK) sunt disponibile și în starea corectă. Nu putem schimba modul de buffering al unui tabel în interiorul unei tranzacții, așa că rutina normală de generare a PK (care va deschide tabelul și va seta BufferMode =1) ar provoca o eroare dacă tabela nu este deja deschisă.

Următoarea parte a declanșatorului începe o tranzacție și inserează numele și acțiunea tabelului (care sunt transmise ca parametri declanșatorului) plus data curentă, ora și id-ul utilizatorului în tabelul antet jurnalului. Această inserție este apoi comisă înainte de a se întreprinde orice altă acțiune.

În cele din urmă, dar tot în cadrul tranzacției, este tratată inserarea în tabelul cu detaliile auditului. O problemă majoră cu înregistrarea de audit este aceea de a preveni ca tabelele de jurnal să devină prea mari - ceea ce poate fi o problemă reală cu tabelele cu activitate ridicată. Codul de aici scrie doar câmpurile care s-au schimbat efectiv atunci când are loc o actualizare - deși întreaga înregistrare trebuie să fie scrisă pentru toate Inseris și Delete - ceea ce ajută la minimizarea dimensiunii tabelelor.

Formularul eșantion, deși simplu, este pe deplin funcțional și permite adăugarea, ștergerea și editarea tabelului „Stoc” de pe prima pagină și utilizează o vizualizare, construită din tabelele jurnalului de audit, pentru a revizui istoricul modificărilor aduse tabelului de pe pagină. Două. Figura 7.6 prezintă cele două pagini ale formularului.

Figura 7.6 Formularul de demonstrare a jurnalului de audit

Și când ar trebui să folosesc o regulă?

Regulile sunt cel mai frecvent utilizate pentru validarea datelor și, deoarece se declanșează pe date stocate în tampon, pot fi folosite pentru a gestiona validarea „pre-salvare”. Prin validare pre-salvare ne referim la verificarea faptului că datele care au fost introduse sau modificate nu vor cauza, în sine, o inserare sau o actualizare. Dacă utilizați o regulă de câmp sau o regulă de masă, va depinde de momentul în care doriți să se declanșeze regula (consultați Tabelul 7.5 pentru detalii).

O altă utilizare comună a regulilor este menținerea câmpurilor calculate (sau dependente) într-o înregistrare. În ciuda faptului că regulile pentru normalizarea datelor la a treia formă normală prevăd că un rând nu trebuie să conțină câmpuri care sunt derivate exclusiv din alte câmpuri din același rând, există multe ocazii când includerea unor astfel de câmpuri este benefică. De obicei, acesta este momentul în care tabelele sunt susceptibile să devină mari și costul general al recalculării valorilor dependente de fiecare dată când se rulează un formular, un raport sau o altă interogare devine inacceptabilă. (Cu alte cuvinte, „denormalizarea pentru performanță”). O astfel de denormalizare poartă cu ea problema de a se asigura că câmpurile calculate sunt menținute corect - dar o regulă simplă, introdusă ca regulă de câmp, va asigura că lucrurile nu pot ieși din sincronizare.

De exemplu, luați în considerare situația în care un tabel este utilizat pentru a înregistra detaliile liniilor de pe o factură. De obicei, veți avea câmpuri pentru Prețul de vânzare și Cantitatea comandată. Pentru a afișa valoarea fiecărei linii, fără a stoca efectiv datele calculate, este nevoie de cod în metodele Valid sau LostFocus ale controlului UI pentru a recalcula valoarea. Prin includerea unui câmp de valoare în tabel, puteți utiliza o regulă și pur și simplu legați un control (numai în citire) la acel câmp. Iată un exemplu de astfel de regulă care ar fi apelată atât de câmpurile Preț de vânzare, cât și de Cantitatea comandată:

FUNCȚIE CheckLineVal

DACĂ NVL(Preț de vânzare, 0) # 0 ȘI NVL(Cantitate comandată, 0) # 0

IF LineValue # SalePrice * Cantitate comandată

ÎNLOCUIȚI LineValue CU (SalePrice * QtyOrdered)

ENDIF

ALTE

IF NVL(LinieValoare, 0) # 0

ÎNLOCUIȚI LineValue CU 0

ENDIF

ENDIF

RETURNARE .T.

Trebuie să-l apelăm din ambele câmpuri pentru a ne asigura că, oricare ar fi schimbat, valoarea este actualizată corect. Rețineți că, de asemenea, verificăm și gestionăm valorile NULL. O regulă foarte similară este folosită în tabelul „Stoc” din exemplul „AuditLog” pentru acest capitol pentru a calcula valoarea stocului deținut.

Un declanșator sau o regulă trebuie să se refere întotdeauna la o singură funcție?

Singura cerință este ca expresia pe care o utilizați pentru a apela un declanșator sau o regulă trebuie să fie întotdeauna evaluată la o valoare logică. Cu condiția să vă construiți expresia de apelare astfel încât Visual FoxPro să o poată evalua la o valoare logică, nu există nicio restricție privind numărul de funcții care pot fi apelate. Următoarele expresii sunt perfect valabile fie ca declanșator, fie ca regulă:

Regula de câmp: SalePrice # 0 ȘI CheckLineVal()

Mesaj: „Prețul de vânzare nu poate fi de 0,00 USD. Pentru a obține un credit, introduceți un preț mai mic de 0,00 USD”

Regulă de câmp: QtyOrdered > 0 AND CheckLineVal()

Mesaj: „Cantitatea nu poate fi 0. Pentru a obține un credit, introduceți Preț mai mic de 0,00 USD”

Folosirea declanșatorilor și a regulilor impune, totuși, o suprasarcină asupra procesului de a face modificări și de a trimite date în tabele. Cu cât regulile tale sunt mai complexe, cu atât navigarea și salvarea rutinelor vor dura mai mult pentru a fi executate. Ca întotdeauna, există un compromis între funcționalitate sporită și performanță. Nivelul care este acceptabil în orice situație poate fi determinat cu adevărat doar prin încercare și eroare în contextul cerințelor aplicației dvs.
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Capitolul 8 - Buffering de date și tranzacții

„Primele greșeli sunt ale lor care le comit, a doua care le permite.” (Proverb englez vechi)

Întregul subiect al utilizării buffer-ului de date și tranzacțiilor în Visual FoxPro este unul intrinsec confuz - care nu este ajutat de alegerea terminologiei asociate cu funcționalitatea. Acest capitol încearcă să demistifice problemele legate de buffering și tranzacții și arată cum puteți utiliza instrumentele oferite de Visual FoxPro pentru a gestiona datele cel mai eficient.
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Utilizarea memoriei tampon de date

De unde venim?

După cum s-a afirmat în introducerea acestui capitol, lucrul cu tamponarea datelor în Visual FoxPro pare să provoace multă confuzie. Considerăm că acest lucru se datorează în mare măsură implementării destul de confuze a tamponării și nomenclaturii oarecum ciudate (după standardele acceptate) asociată cu subiectul.

De exemplu, pentru a seta buffering pentru un fișier Visual FoxPro DBF (care este un tabel), trebuie să folosim funcția CDRÆQRSETPROP() foarte supraîncărcată. De ce nu o funcție separată, fără ambiguitate, „SetBufferMode()”? În timp ce pentru a confirma o tranzacție în așteptare, comanda este END TRANZACȚIE. De ce nu „commit” ca în orice altă limbă de bază de date – o alegere care este și mai particulară, deoarece comanda standard „rollback” este folosită pentru a anula o tranzacție?

În plus, poate din cauza modului în care Visual FoxPro implementează blocarea înregistrărilor (spre deosebire de „pagină”), problema controlului plasării și eliberării încuietorilor este aparent legată inextricabil de tamponarea. De exemplu, pentru a activa tamponarea rândurilor, care funcționează doar pe o singură înregistrare, SET MULTILOCKS trebuie să fie ON - dar, conform fișierului Ajutor, această setare determină doar capacitatea Visual FoxPro de a bloca mai multe înregistrări în același tabel - și este definită. oricum la sesiunea curentă de date. Acest lucru nu pare foarte logic și nu este chiar surprinzător că suntem confuzi de toate acestea.
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Oricum, ce înțelegem prin „buffering”?

Principiul este de fapt foarte simplu. Conceptul de stocare în tampon este că, atunci când faceți modificări la date, acele modificări nu sunt scrise direct în tabelul sursă, ci intră într-o „zonă de stocare” („Buffer”) până în momentul în care solicitați Visual FoxPro fie să salveze. să le depoziteze permanent sau să le arunce. Figura 8.1 ilustrează conceptul. Această zonă de stocare este ceea ce „vedeți” de fapt în Visual FoxPro când utilizați un tabel tamponat și este, în realitate, un cursor actualizabil bazat pe tabelul sursă. Toate modificările sunt făcute acestui cursor și sunt scrise în tabelul de bază numai atunci când este emisă comanda „update” corespunzătoare.

Figura 8.1 Buffering de date conceptualizat

Strategii de tamponare

Tabelele pot fi utilizate cu trei „strategii de tamponare” diferite. Prima opțiune este să nu utilizați deloc tamponarea.

Aceasta a fost singura opțiune din toate versiunile de FoxPro înainte de Visual FoxPro Versiunea 3.0 și este încă comportamentul implicit pentru tabelele Visual FoxPro astăzi. Acest mod poate fi setat în mod explicit folosind

CURSORSETPROP ( ' Buffering ' ) cu un parametru de „1”. Orice modificări efectuate sunt scrise direct și imediat în tabelul de bază. Nu există nicio capacitate de „anulare” decât dacă este programată explicit, folosind SCATTER și GATHER, de exemplu.

A doua opțiune este pentru „Rând”, care este setată folosind CURSORSETPROP(‘Buffering’) cu un parametru fie „2” fie „3”. Modificările nu sunt trimise la tabelul de bază decât dacă se întâmplă unul dintre cele două lucruri. Fie o comandă explicită TableUpdate() sau TableRevert() este emisă în cod, fie înregistrarea

indicatorul este mutat în tabelul de bază. Orice mișcare a indicatorului de înregistrare, oricum este inițiată pentru un tabel care se află în modul tampon de rând, provoacă întotdeauna un „TableUpdate() implicit.

A treia opțiune este pentru tamponarea „Tabel”, care este setată folosind CURSORSETPROP('Buffering') cu un parametru fie „4” fie „5”. În acest mod, modificările nu sunt niciodată trimise „automat” către tabelul de bază, trebuie întotdeauna utilizată o comandă explicită TableUpdate() pentru a trimite modificările din buffer către tabelul de bază, sau TableRevert() pentru a anula modificările. Încercarea de a închide un tabel cu tampon de tabel în timp ce acesta are încă modificări necommitate a determinat ca Visual FoxPro să genereze o eroare în versiunea 3.0, dar acest comportament a fost modificat în versiunile ulterioare, astfel încât modificările în așteptare sunt pur și simplu pierdute. Nu există nicio eroare și nici un avertisment că modificările sunt pe cale să se piardă, tabela tamponată este doar închisă.

Strategii de blocare

Strâns aliată cu tamponarea este problema „blocării”. Visual FoxPro trebuie întotdeauna să blocheze înregistrarea fizică într-un tabel în timp ce se fac modificări la conținutul acestuia și există două strategii posibile.

În primul rând, o înregistrare poate fi blocată de îndată ce un utilizator începe să facă modificări. (Blocarea este de fapt plasată de îndată ce este detectată o apăsare de tastă validă.) Aceasta este „Blocare pesimistă” și împiedică orice alt utilizator să facă sau să salveze modificări la înregistrarea respectivă până când utilizatorul actual a finalizat modificările și a eliberat înregistrarea de către fie comiterea, fie anularea modificărilor acestora.

În al doilea rând, Visual FoxPro poate încerca să blocheze o înregistrare numai atunci când modificările sunt trimise la tabel. Aceasta este „Blocare optimistă” și înseamnă că, deși un utilizator efectuează modificări datelor, înregistrarea rămâne disponibilă pentru alți utilizatori care ar putea, de asemenea, să facă și, eventual, să salveze, modificări în aceeași înregistrare în timp ce primul utilizator încă o lucrează.

Moduri de tamponare

„Modul” buffer pentru un tabel este, prin urmare, combinația specifică a strategiilor de Buffering și Locking. Există un total de cinci moduri de tamponare pentru un tabel, așa cum este ilustrat în Tabelul 8.1.

Tabelul 8.1 Moduri de buffering Visual FoxPro

Mode 	LockingBufferingComment
1 	PesimistNoneSingura opțiune pentru FP2.x, implicită pentru VFP, tabele
2 	PessimisticRowLock plasat de KeyPress Event. Înregistrați mișcarea indicatorului forțelor de salvare
			

3 	OptimisticRowLock plasat de TableUpdate(). Înregistrați mișcarea indicatorului forțelor de salvare
4 	PessimisticTableLock plasat de KeyPress Event. Salvarea trebuie să fie inițiată în mod explicit
5 	OptimisticTableLock plasat de TableUpdate(). Salvarea trebuie să fie inițiată în mod explicit

Când lucrăm cu Visual FoxPro, trebuie să fim atenți să distingem între strategiile individuale pe care le setăm pentru Buffering și Locking și modul de tamponare care rezultă din combinarea acestora. Din păcate, după cum vom vedea, Visual FoxPro în sine este mai puțin atent la această distincție.
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Ce înseamnă toate acestea atunci când creați formulare legate de date?

Aici lucrurile încep să devină puțin mai complexe (și nu numai din cauza nomenclaturii). Să luăm în considerare situația „normală” în care tabelele sunt adăugate pentru a forma de către mediul de date nativ. Formularul are o proprietate numită „Buffermode” care are trei setări posibile:

• 	0 Niciunul (implicit)

• 	1 Pesimist

• 	2 Optimist

Observați că acestea se referă de fapt la opțiunile pentru strategia de blocare și nu au nimic de-a face cu tamponarea! De fapt, forma va determina singura strategia de tamponare pentru tabelele sale, pe baza utilizării lor.

Exemplul de cod include două forme „DemOne” (Figura 8.2) și „DemTwo” (Figura 8.3) care, atunci când sunt inițializate, afișează valorile pentru proprietatea Buffermode a formularului și modul de stocare tampon al fiecărui tabel în casetele text etichetate. (Modul tampon al formularului poate fi setat doar în momentul proiectării, așa că deschideți formularul și schimbați Modul tampon, apoi rulați-l pentru a vedea rezultatele pentru diferite setări.) Ambele formulare folosesc aceleași două tabele, care au o tabele unu-la- multe relații, dar ele afișează partea „mulți” a relației în moduri diferite. Primul folosește o grilă, în timp ce al doilea pur și simplu arată câmpuri individuale direct pe formular.

Figura 8.2 Setare automată a modului tampon atunci când o grilă este prezentă pe formular

Observați că atunci când tabelul „multe” este afișat într-o grilă, acesta este deschis, prin formular, în modul tampon de tabel. Cu toate acestea, dacă tabelul „multe” afișează doar câmpuri unice, atunci tamponarea pentru tabel va fi aceeași ca și pentru tabelul „unu” pentru toate setările proprietății Buffermode a formularului.

Figura 8.3 Setare automată a modului tampon fără grilă

Dacă parcurgeți toate opțiunile pentru proprietatea Buffermode a formularului, veți fi observat că, chiar și cu proprietatea BufferMode a formularului setată la O-( Niciunul), cursorul creat de Visual FoxPro este tot deschis în modul buffer de rând atunci când tabelele sunt deschise de către mediul de date al formularului. „Fără buffering” înseamnă aparent „Row Buffering” pentru un formular!

Cu toate acestea, acesta NU este cazul când tabelele sunt deschise direct cu o comandă USE. Formularul „DemThree” este identic cu „DemOne”, cu excepția faptului că, în loc să folosească mediul de date al formularului pentru a deschide tabelele, ele sunt deschise explicit în metoda Load. În această situație, proprietatea Buffermode a formularului nu are niciun impact, iar tabelele sunt deschise conform setărilor din secțiunea „Blocare și Buffering” din fila „Date” din dialogul Opțiuni. Acest dialog setează într-adevăr modul tampon. Are opțiuni rive care corespund modurilor river definite în Tabelul 8.1 de mai sus și care folosesc aceiași identificatori numerici ca și funcția CursorSetProp ().

Cu toate acestea, setările specificate în caseta de dialog Opțiuni se aplică numai sesiunii de date implicite. Dacă formularul rulează o sesiune de date privată, atunci tabelele deschise cu comanda de utilizare vor fi setate în orice mod este specificat pentru acea sesiune de date și acesta, în mod implicit, nu va fi deloc pentru buffering.

esti inca confuz?

Sigur suntem! Din câte putem spune, situația este de fapt următoarea:

• Pentru tabelele deschise de mediul de date al unui formular, nu contează dacă formularul rulează în sesiunea de date implicită sau privată. Tabelele sunt întotdeauna stocate cel puțin la nivel optimist Row.

• 	Proprietatea BufferMode a formularului determină de fapt strategia de blocare, nu modul buffer, ci numai pentru tabelele care sunt deschise de mediul de date al formularului respectiv.

• 	În sesiunea de date implicită, tabelele care sunt deschise în mod explicit au atât strategiile de tamponare, cât și de blocare setate la opțiunea aleasă în Dialogul Opțiuni global.

• 	Într-o sesiune de date privată, tabelele care sunt deschise în mod explicit au strategiile lor de tamponare și blocare setate în funcție de setările care se aplică pentru acea sesiune de date (Implicit = „Fără tamponare”).

Aceste rezultate pot fi verificate prin setarea diferitelor opțiuni din cele trei formulare demonstrative.
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Deci, cum configurez tamponarea într-un formular?

Răspunsul scurt, ca întotdeauna, este „depinde”. Dacă utilizați mediul de date al formularului pentru a deschide tabele, atunci puteți lăsa în mod normal opțiunea de buffering la Visual FoxPro. În caz contrar, puteți utiliza pur și simplu funcția CursorSetProp() din codul dvs. pentru a configura fiecare tabel după cum este necesar. În orice caz, trebuie să fii conștient de consecințe, astfel încât să poți codifica rutinele de actualizare în mod corespunzător.

Folosind BufferModeOverride

Clasa dataenvironment oferă o proprietate pentru fiecare tabel (sau, mai precis, „cursor”), numită „BufferModeOverride”. Aceasta va seta modul tampon pentru acel tabel (și numai acel tabel) la una dintre cele șase opțiuni ale sale - da, asta este corect, șase opțiuni, nu cinci - după cum urmează:

• 	0 Nici unul

• 	1 (Implicit) Utilizați setarea formularului

• 	Buffering pe 2 rânduri pesimistă

• 	Buffering optimist cu 3 rânduri

• 	4 Buffering pesimist de masă

• 	5 tamponare optimistă a tabelului

În primul rând, observați că, în timp ce numerele de la 2 la 5 se potrivesc cu parametrii pentru CursorSetProp() și sunt aceleași cu cei disponibili prin dialogul Opțiuni, valoarea necesară pentru setarea „fără tamponare” este acum 0 în loc de 1. Aceasta este încă o inconsecvență în configurat pentru tamponare!

În al doilea rând, observați că valoarea implicită pentru această proprietate este „1 - Utilizați setarea formularului”. Forma „setare” la care se face referire este, desigur, proprietatea „BufferMode” care, după cum am văzut, este de fapt pentru alegerea strategiei de blocare care urmează să fie aplicată. Nu există nicio setare de formular pentru controlul tamponării!

Acestea fiind spuse, setarea proprietății BufferModeOverride se va asigura că tabelul este deschis folosind modul tampon pe care îl specificați. Cel puțin această proprietate este denumită corect, suprascrie orice altceva și forțează tabelul în modul tampon specificat în toate situațiile.

Folosind CursorSetProp()

Indiferent de modul în care este deschis un tabel, puteți utiliza întotdeauna funcția CursorSetProp() pentru a schimba modul tampon al unui tabel. Cu toate acestea, dacă nu utilizați mediul de date al formularului pentru a vă deschide tabelele, atunci aveți două opțiuni, în funcție de dacă formularele dvs. utilizează DataSession implicită sau Private DataSession. În primul caz, puteți pur și simplu să setați modul dorit în dialogul Opțiuni și să uitați de el. Toate mesele vor fi întotdeauna deschise cu această setare și veți ști întotdeauna unde vă aflați.

Dacă utilizați o sesiune de date privată, atunci trebuie să faceți două lucruri. În primul rând, trebuie să vă asigurați că mediul este configurat pentru a suporta tamponarea. O serie de setări de mediu sunt incluse în sesiunea de date și poate fi necesar să modificați comportamentul implicit al unora sau al tuturor dintre următoarele (consultați subiectul SETARE DATASESSION din fișierul de ajutor pentru o listă completă a setărilor afectate):

• 	SET MULTILOCKS Trebuie setat la ON pentru a activa tamponarea, implicit este OFF

. SET DELETED Implicit este OFF

• 	SET DATABASE „Fără bază de date” este setat implicit într-o sesiune de date privată

• 	SETARE EXCLUSIV Valoarea implicită este DEZACTIVATĂ pentru o sesiune de date privată

• 	SET LOCK Implicit este OFF

• 	SET COLLATE Implicit este „MACHINE”

. SET EXACT Implicit este OFF

În al doilea rând, trebuie să setați în mod explicit modul tampon al fiecărui tabel folosind funcția CursorSetProp () cu parametrul corespunzător, deoarece setările din Dialogul Opțiuni nu se aplică sesiunilor de date private.
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Deci, ce mod de tamponare ar trebui să folosesc în formularele mele?

Pentru noi răspunsul este simplu. Ar trebui să utilizați întotdeauna tamponarea tabelului cu o strategie de blocare optimistă (de exemplu, Modul tampon 5). Motivul este pur și simplu că, cu excepția construirii unui index, nu puteți face nimic în alt mod care nu poate fi făcut în acest mod. Deși tamponarea rândurilor poate fi utilă în dezvoltare, nu credem că are loc într-o aplicație de lucru. Există prea multe moduri în care implicit TableUpdate() (cauzat de mutarea pointerului de înregistrare) poate fi declanșat și nu toate dintre ei se află sub controlul nostru direct. De exemplu, funcția KeyMatch() este definită în fișierul Ajutor ca;

Caută o cheie de index într-o etichetă index sau într-un fișier index

Pare destul de inofensiv - cu siguranță căutarea unui fișier index nu poate cauza probleme. Dar o notă (în secțiunea Observații chiar la sfârșitul subiectului) mai spune că:

KEYMATCH( ) returnează indicatorul de înregistrare la înregistrarea pe care a fost poziționat inițial înainte ca KEYMATCH( ) să fie emis.

Stai chiar acolo! Cu siguranță „întoarce indicatorul de înregistrare” implică faptul că mută indicatorul de înregistrare - ceea ce face într-adevăr. Consecința este că, dacă utilizați buffering de rând și doriți să verificați o cheie duplicată folosind ведомо, veți efectua imediat orice modificare în așteptare. (Desigur, în versiunea 6.0 sau ulterioară, puteți utiliza întotdeauna IndexSeek() în schimb.) Cu toate acestea, aceeași problemă apare cu multe dintre comenzile și funcțiile care operează pe o masă - în special cele mai vechi care au fost introduse în FoxPro înainte de zilele de tamponare (de ex. CALCULATE, SUM și medie).

Faptul că aveți o tabelă configurată pentru tamponarea tabelului nu vă împiedică să tratați tabelul ca și cum ar fi de fapt în buffer de rând. Atât funcțiile TableUpdate() și TableRevert() au capacitatea de a acționa numai asupra rândului curent. Prin urmare, singura diferență practică este că nu se va face nicio actualizare decât dacă apelați în mod explicit TableUpdate(). Acest lucru poate însemna că trebuie să scrieți puțin mai mult cod, dar previne o mulțime de probleme.
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Schimbarea modului tampon al unui tabel

Am spus, la începutul ultimei secțiuni, că puteți utiliza oricând cursorse«ropo pentru a seta sau a schimba modul de stocare a unui tabel. Acest lucru este adevărat, dar dacă tabelul este deja stocat în tabel, s-ar putea să nu fie atât de simplu, deoarece modificarea stării tamponării va forța Visual FoxPro să verifice starea oricăror buffer-uri existente.

Dacă tabelul este Row Buffered și are modificări necomitate, Visual FoxPro pur și simplu comite modificările și permite schimbarea modului. Cu toate acestea, dacă ținta are un buffer de tabel și încercați să îi schimbați modul tampon în timp ce există modificări necommitate, Visual FoxPro se plânge și generează eroarea 1545 („Bufferul de tabel pentru alias „nume” conține modificări necommitate”). Aceasta este o problemă, deoarece nu puteți indexa un tabel în timp ce acesta este în buffer de tabel, așa că singura modalitate de a crea un index pe un astfel de tabel este să comutați, temporar, la tamponarea rândurilor. Desigur, soluția este destul de simplă - asigurați-vă că nu există modificări în așteptare înainte de a încerca să schimbați modul tampon. Dar cum poți face asta?
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IsChanged() - o altă funcție pe care FoxPro a uitat-o?

Visual FoxPro oferă două funcții native care pot fi utilizate pentru a verifica starea bufferelor -GetFldState() și GetNextModified(). Cu toate acestea, primul dintre acestea funcționează numai pe rândul curent al unui tabel, iar al doilea poate fi utilizat numai atunci când Table Buffering este în vigoare. Ni se pare că ceea ce lipsește este o singură funcție care va funcționa în toate situațiile și vă va anunța dacă există modificări în așteptare într-un buffer de tabel. Iată încercarea noastră de a scrie o astfel de funcție:

**************************************************** ********************

* 	Program. IsChanged.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Abstract...: Returnează o valoare logică care indică dacă un tabel are

* 	..........:modificări în așteptare, indiferent de modul tampon utilizat

**************************************************** ********************

LPARAMETRI tcTable

LOCAL lcTable, lnBuffMode, lnRecNo, llRetVal, lcFldState

*** Verificați parametrul, presupuneți aliasul curent dacă nu a trecut nimic

lcTable = IIF( VARTYPE(tcTable) # "C" SAU EMPTY( tcTable ), ;

ALIAS(), ALLTRIM( UPPER( tcTable )))

*** Verificați dacă numele tabelului specificat este folosit ca alias

DACĂ GOL (lcTable) SAU ! FOLOSIT( JUSTSTEM( lcTable) )

*** Avem o eroare - probabil o eroare a dezvoltatorului, așa că folosiți o eroare pentru a o raporta! EROARE "9000: IsChanged() necesită ca aliasul unui tabel deschis să fie" + CHR.(13) ;

+ "a trecut, sau că zona de lucru curentă ar trebui să conțină un" + CHR(13) ;

+ „deschide masa”

RETURNARE .F.

ENDIF

*** Verificați starea tamponării

lnBuffMode = CURSORGETPROP( 'Buffering', lcTable )

*** Dacă nu există tampon, doar returnați .F.

IF lnBuffMode = 1

RETURNARE .F.

ENDIF

*** Acum ocupă-te de cele două moduri tampon

IF INLIST( lnBuffMode, 2, 3 )

*** Dacă rândul este tamponat, utilizați GetFldState()

lcFldState = NVL( GETFLDSTATE( -1, lcTable ), "")

*** Dacă lcFldState conține ceva în afară de 1, atunci ceva s-a schimbat

*** Toate cele 3 indică o înregistrare goală, atașată, dar aceasta este încă o schimbare!

*** Folosiți CHRTRAN pentru a elimina 1 - și vedeți dacă a mai rămas ceva.

llRetVal = !EMPTY( CHRTRAN( lcFldState, "1", "") )

ALTE

*** Găsiți numărul de înregistrare al primei înregistrări modificate.

*** Înregistrările anexate vor avea un număr de înregistrare care este negativ

*** deci trebuie să verificăm pentru o valoare returnată de „NU EGAL CU 0”,

*** mai degrabă decât pur și simplu „MAI MAI MULT DE 0”

llRetVal = ( GETNEXTMODIFIED( 0, lcTable ) # 0 )

ENDIF

RETURN lLRetVal

În esență, tot ceea ce face această funcție este să determine tipul de buffering folosit și să folosească funcția nativă corespunzătoare pentru a vedea dacă există modificări. Există, totuși, câteva ipoteze aici. În primul rând, funcția vede un rând nou adăugat, dar total needitat, ca „o schimbare”. Acest lucru este rezonabil, deoarece singurul obiectiv este de a determina dacă tabelul s-a modificat, nu dacă modificarea trebuie salvată sau nu. În al doilea rând, pentru tabelele care utilizează moduri de tamponare de 4 sau 5, nu se oferă nicio indicație despre câte modificări pot exista sau dacă „rândul curent” s-a schimbat de fapt. Din nou, având în vedere obiectivul, acest lucru este rezonabil.

Ar fi perfect posibil să se modifice codul pentru a aborda aceste probleme (poate prin returnarea unei valori numerice care indică condiții diferite, mai degrabă decât un simplu „da/nu”). În opinia noastră, totuși, acest lucru ar putea face funcția prea specifică pentru a fi calificată drept candidat pentru un fișier de procedură generică, care este locul în care am dori să plasăm funcția.

Am inteles! la adăugarea înregistrărilor cu valori implicite

Există, totuși, o problemă potențială la care trebuie să fiți atenți atunci când utilizați o rutină precum aceasta. Dacă adăugați o înregistrare nouă la un tabel care furnizează o valoare implicită pentru unul sau mai multe câmpuri, veți obține un rezultat „fals pozitiv” atunci când testați o înregistrare neschimbată altfel. Acest lucru se datorează faptului că Visual FoxPro inserează o valoare implicită după ce înregistrarea este atașată și, prin urmare, este văzută de funcțiile care testează câmpurile ca „schimbate”. Din fericire, există o soluție - funcția SETFLDSTATE() poate fi folosită pentru a șterge starea schimbată a unui anumit câmp.

Există o limită! setFlastateo utilizează aceleași valori numerice ca cele returnate de funcția GetFldState(), astfel încât valorile 1 sau 2 se referă la înregistrările editate, în timp ce 3 și 4 se referă la înregistrările atașate. Nu puteți utiliza setFlastateo pentru a modifica starea înregistrării, ci doar a câmpurilor individuale. Astfel, nu puteți spune VFP că o înregistrare în curs de editare este dintr-o dată o înregistrare nou adăugată prin schimbarea stării tuturor câmpurilor sale la „3”, sau că o înregistrare atașată este de fapt editată prin schimbarea câmpurilor sale în starea „2”. Următorul cod arată ce se întâmplă:

*** Deschideți Tabelul, adăugați o înregistrare și verificați starea

USE demone

CURSORSETPROP( „Buffering”, 5)

ANEXĂ GOL

? GETFLDSTATE( -1 ) && returnează „3433”

Amintiți-vă, GetFldState( -1 ) include întotdeauna starea steagului Șters al înregistrării ca prim element din șirul său returnat. Deci, valoarea returnată aici indică de fapt că primul câmp din tabel s-a schimbat (cum era de așteptat, deoarece este câmpul SID și are o valoare implicită specificată).

*** Acum încercați să schimbați starea câmpului pentru câmpul Cheie

*** La „Needitat”

? SETFLDSTATE( 1, 1 )

Aceasta generează imediat eroarea 11, „Valoarea argumentului funcției, tipul sau numărul nu sunt valide”, deoarece înregistrarea nu este editată, este o înregistrare atașată. Cu toate acestea, următoarele:

*** Schimbați starea câmpului pentru câmpul Cheie

*** La „Neschimbat”

? SETFLDSTATE( 1, 3 ) && Returnează .T.

? GETFLDSTATE( -1 ) && Acum returnează „3333”

este perfect acceptabil, iar IsChanged() va returna acum numai consecințele acțiunilor inițiate de utilizator și nu va vedea modificările care decurg din utilizarea valorilor implicite. Locul evident pentru a pune un astfel de cod este într-o metodă hook numită din cea care adaugă de fapt noua înregistrare. O astfel de metodă ar putea folosi IsChanged() pentru a determina dacă au fost furnizate valori implicite și poate folosi SetFldState() pentru a reseta starea câmpului înregistrării.

Am inteles! Folosind GetFldState() când un tabel este la EOF()

Un cuvânt de precauție despre utilizarea GetFldState() (care nu este menționat în fișierele de ajutor VFP). Dacă tabelul pe care îl testați se întâmplă să fie la EOF(), funcția va returna o valoare NULL în loc de tipul de date așteptat. Trebuie să vă asigurați că gestionați corect această situație utilizând întotdeauna funcția NVL() pentru a converti orice returnare nulă înapoi într-un șir gol atunci când utilizați parametrul „-1” astfel:

lcFldState = NVL( GetFldState(-1), "" )

sau, dacă testați un anumit câmp, pentru a converti înapoi în tipul de date numerice așteptat:

lcFldState = NVL( GetFldState("nume"), 0 )

Dacă nu reușiți să faceți acest lucru, atunci orice cod care testează valoarea returnată va eșua din cauza modului în care sunt propagate NULL-urile.

Interpretarea valorilor NULL: constatăm că cel mai bun mod de a ne gândi la o valoare nulă este să o traducem prin „nu știu”. Când este privit în această lumină, comportamentul valorilor NULL este clar - răspunsul la orice întrebare despre statutul unui lucru a cărui valoare este „Nu știu” va fi întotdeauna „Nu știu!” Prin urmare:

llTestVal = .NULL.

*** llTestVal este gol?

? EMPTY(llTestVal) && Răspuns: .F. („Nu știu” NU este o valoare definită ca „Gol”)

*** Este llTestVal mai mare decât 0

? llTestVal > 0 && Răspuns: .NULL. ('Nu știu')

*** Numele este fie Dave, fie Fred?

? INLIST(llTestVal, „Dave”, „Fred”) && Răspuns: .NULL. ('Nu știu')
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Folosind TableUpdate() și TableRevert()

Când lucrați cu date tamponate, două funcții sunt absolut vitale - și anume TableUpdate() și TableRevert(). Acestea sunt mijloacele de bază prin care controlați transferul de date între bufferele Visual FoxPro și sursa de date subiacentă. TableUpdate() preia modificările în așteptare din buffer-uri și le trimite în tabelul de bază, în timp ce TableRevert() reîmprospătează tampoanele prin recitirea datelor din sursa de date subiacentă. Finalizarea cu succes a oricărei funcții are ca rezultat un buffer „curat”, ceea ce înseamnă că, în ceea ce privește Visual FoxPro, bufferele și sursa de date de bază sunt sincronizate.

Gestionarea domeniului actualizărilor

Deoarece Visual FoxPro acceptă atât stocarea în buffer pentru rânduri, cât și pentru tabel, ambele funcții de transfer de date pot funcționa fie pe „numai înregistrarea curentă”, fie pe „toate înregistrările modificate”. Primul parametru care este transmis oricărei funcții determină domeniul de aplicare și, din păcate, avem o altă sursă de posibilă confuzie chiar aici. Funcțiile funcționează în moduri ușor diferite și folosesc valori de returnare diferite.

În versiunea 3.0 a Visual FoxPro, atât TableUpdate() cât și TableRevert() ar accepta doar un parametru logic pentru a determina domeniul de aplicare al modificării pe care au gestionat-o. Transmiterea unei valori de .t. a însemnat că toate modificările în așteptare urmau să fie acționate, în timp ce .f. operațiuni limitate numai la rândul curent, indiferent de modul tampon în vigoare.

TableRevert() returnează numărul de rânduri care au fost inversate și nu pot „eșua” cu adevărat - cu excepția cazului în care există o problemă fizică, cum ar fi pierderea unei conexiuni la rețea. Într-un tabel cu buffer de rând sau când se specifică domeniul de aplicare ca .f., valoarea returnată va fi, prin urmare, întotdeauna i.

TableUpdate() returnează întotdeauna o valoare logică care indică dacă actualizarea specificată a reușit, indiferent de domeniul de aplicare. Cu alte cuvinte, o valoare returnată de .T indică faptul că toate înregistrările din domeniu au fost actualizate cu succes. Cu toate acestea, când utilizați un parametru logic pentru a determina domeniul de aplicare și actualizarea eșuează din orice motiv, nu este generată nicio eroare și funcția returnează o valoare de .f. lăsând indicatorul de înregistrare la înregistrarea care a eșuat.

Dacă actualizați o singură înregistrare, acest lucru este destul de simplu, dar dacă actualizați mai multe înregistrări dintr-un tabel și o înregistrare nu poate fi actualizată, înseamnă că alte actualizări nu au fost testate. Deci, după rezolvarea conflictului pentru înregistrarea care a eșuat, nu există nicio garanție că retrimiterea actualizării nu va eșua chiar în următoarea înregistrare. Aceasta poate fi o problemă!

Comportamentul TableUpdate() a fost, prin urmare, modificat în versiunea 5 pentru a accepta fie un parametru logic, fie unul numeric pentru domeniu, unde 0 este echivalent cu utilizarea .f. și eu să folosesc .t. Noul comportament, care poate fi specificat doar prin trecerea „2” ca parametru de domeniu, abordează în mod specific problemele actualizării mai multor înregistrări.

Când se folosește tamponarea tabelului, apelarea TableUpdate() cu un parametru de domeniu de „2” încearcă să actualizeze toate înregistrările care au modificări în așteptare. Cu toate acestea, dacă o înregistrare nu poate fi actualizată, în loc să oprească funcția, înregistrează numărul de înregistrare care nu a reușit într-o matrice (pe care îl puteți specifica ca al patrulea parametru) și continuă să încerce să actualizeze orice alte înregistrări modificate. Funcția va reveni în continuare .F. dacă vreo înregistrare nu reușește să se actualizeze, dar va fi încercat cel puțin să actualizeze toate înregistrările disponibile. Matricea de ieșire conține o listă a numerelor de înregistrare care nu s-au actualizat.

Al doilea parametru (forță) al TableUpdate().

O diferență majoră între sintaxa pentru TableUpdate() și TableRevert() este că primul poate lua un parametru suplimentar, logic, în a doua poziție din lista de parametri. Aceasta controlează modul în care se comportă actualizarea ori de câte ori este întâlnit un conflict.

În mod implicit, Visual FoxPro va respinge o actualizare ori de câte ori este detectat un conflict între datele din buffer și datele subiacente (consultați secțiunea următoare pentru o discuție completă despre detectarea și rezolvarea conflictelor). Specificând un „.T” logic ca al doilea parametru, puteți forța acceptarea unei actualizări chiar și în situațiile în care altfel ar eșua. Desigur, acest lucru nu este ceva ce ați dori să faceți în mod implicit, dar există, așa cum vom vedea mai târziu, situații în care acest comportament nu este doar de dorit, ci și esențial.

Specificarea tabelului care urmează să fie actualizat sau inversat

Atât TableUpdate() cât și TableRevert() operează pe un singur tabel la un moment dat. Comportamentul lor implicit este că, cu excepția cazului în care este indicat altfel, ei vor acționa pe masă în zona de lucru selectată în prezent. Dacă nu este deschis niciun tabel în această zonă de lucru, veți primi o eroare (Eroarea #13: Alias nu este găsit). Ambele, totuși, pot acționa asupra oricărui tabel deschis disponibil în sesiunea de date curentă și pot accepta fie un nume ALIAS (al treilea parametru pentru TableUpdate(), al doilea pentru TableRevert()), fie un număr de zonă de lucru.

Nu recomandăm utilizarea numerelor zonei de lucru în această situație sau în oricare altă situație în care specificați un alt tabel decât cel selectat în prezent. Din câte putem vedea, această funcționalitate este inclusă doar pentru compatibilitate cu versiunea anterioară și nu are loc în mediul VFP. Există două motive pentru a evita utilizarea numerelor zonei de lucru. În primul rând, vă fac codul dependent de anumite tabele care sunt deschise în anumite zone de lucru - ceea ce este o limitare majoră dacă lucrurile se schimbă! În al doilea rând, oricum nu aveți niciun control asupra locului în care VFP deschide tabele, cursoare sau vizualizări atunci când utilizați un mediu de date al formularului. Deci, bazarea pe numărul zonei de lucru, mai degrabă decât pe alias, este o strategie foarte riscantă și nu este necesară.

Singura dată când vă recomandăm să folosiți numărul zonei de lucru este atunci când salvați zona de lucru curentă prin stocarea valorii de returnare a funcției SELECT(). Utilizarea numărului zonei de lucru în acest caz asigură că, în cazul în care zona de lucru curentă este de fapt goală sau tabelul pe care îl conține este închis în timpul oricărei operațiuni pe care o faceți, puteți reveni la ea fără eroare.

Concluzie

Există o mulțime de funcționalități și flexibilitate ascunse în TableUpdate() și TableRevert(). Când utilizați tamponarea, trebuie să fiți conștient de exact ce pot oferi diferitele combinații ale parametrilor acestora și să vă asigurați că utilizați combinația corectă pentru a vă satisface nevoile. În timp ce TableRevert() este destul de simplu, TableUpdate() este mai complex și astfel Tabelul 8.2 de mai jos oferă un rezumat al diferitelor combinații „practice” de parametri pentru TableUpdate().

Tabelul 8.2 Opțiuni TableUpdate().

Parametrii				
Domeniu 	ForceTableOutputAction
0 sau .F. 	.F. 			Încercați să actualizați numai rândul curent al aliasului curent.
0 sau .F. 	.T. 			Forțați actualizarea rândului curent numai a aliasului curent.
0 sau .F. 	.F./.TAlias 		Încercare/Forțare actualizarea rândului curent numai al aliasului specificat.
1 sau .T. 	.F. 			Încercați să actualizați toate rândurile disponibile ale aliasului curent. Opriți la eșec.
1 sau .T. 	.T. 			Forțați actualizarea tuturor rândurilor disponibile ale aliasului curent.
1 sau .T. 	.F./.T.Alias 		Încercare/Forțare actualizare a tuturor rândurilor disponibile ale aliasului specificat. Opriți pe eșec.
2 	.F.AliasArray	

				Încercați toate să actualizați toate rândurile disponibile ale aliasului specificat. Observați eșecurile, dar nu vă opriți.
2 	.T 			Forțați actualizarea tuturor rândurilor disponibile de alias curent/specificat.
2 	.F./.TAliasArrayAttempt/Force actualizarea tuturor rândurilor disponibile ale aliasului specificat. Observați eșecurile, dar nu vă opriți.
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Cum pot gestiona funcționalitatea „salvare” și „anulare” în mod generic?

Ni se pare că mulți dezvoltatori scriu această funcționalitate direct în obiectele de interfață iar și iar. Motivul este de obicei că „fiecare formă are cerințe diferite” - dar este acest lucru cu adevărat adevărat? Nu suntem atât de siguri. Procesul real de actualizare sau revenire a unui tabel este întotdeauna același. Singurele probleme sunt când o faci, care este determinat de procesele de validare, și ce faci când ceva nu merge bine. Acestea sunt ambele probleme serioase și depind într-adevăr de situație, dar nici nu afectează procesul de actualizare efectivă sau de revenire a unui tabel!

Prin urmare, redusă la elementele de bază, singura problemă reală apare atunci când trebuie să gestionați mai multe tabele simultan, deoarece TableUpdate() și TableRevert() se așteaptă să primească un singur nume de tabel pe care să funcționeze . Pseudocodul pentru o metodă generică „Salvare” arată așadar cam așa:

Primiți Allas din toate tabelele pentru a actualiza ca o listă separată prin virgulă

Pentru fiecare tabel din listă

Verificați starea tamponării

Emiteți varianta corespunzătoare a TableUpdate()

Creați o listă cu orice erori

Întoarceți rezultatul

În timp ce pentru o metodă generică „Anulare”, codul este într-adevăr foarte asemănător:

Primiți alias pentru toate tabelele pentru a reveni ca o listă separată prin virgulă

Pentru fiecare tabel din listă

Verificați starea tamponării

Emiteți varianta corespunzătoare a TableRevert()

Întoarceți rezultatul

Am discutat deja despre o funcție pentru preluarea unui articol dintr-o listă separată prin virgulă (vezi GetItem() în Capitolul 2), așa că singura problemă reală este unde ar trebui să meargă codul? Există două opțiuni de bază. În primul rând, codul ar putea fi implementat ca parte a unei clase de „prelucrare a datelor” care ar putea fi pur și simplu adăugată la formularele care necesită funcționalitatea. În al doilea rând, metodele necesare pot fi incluse ca parte a unei clase de formulare „Data-Aware”. Am ales să ilustrăm abordarea claselor de formular deoarece marea majoritate a aplicațiilor Visual FoxPro sunt în esență bazate pe formular. Ocaziile în care ar fi necesar un obiect de date separat sunt, prin urmare, mai degrabă excepții decât o regulă.

Designul clasei de formulare

Pentru a implementa funcționalitatea Salvare și Anulare pentru un formular, trebuie mai întâi să setăm clasa noastră de formular pentru a furniza metodele necesare. Am ales să oferim un set de metode șablon în clasa noastră de formulare „Root” (xFrm în RootClas.vcx) care va gestiona procesul de salvare prin implementarea unui model Hook.

Metoda SaveForm este controlerul procesului și este metoda pe care o apelează codul într-o instanță a unui formular bazat pe această clasă pentru a încerca efectiv o „salvare”. Metoda SaveForm face mai întâi un apel la metoda BeforeSave. Orice cod specific unei instanțe care trebuie apelat imediat înainte de salvarea efectivă (de exemplu, validarea pre-salvare) va fi plasat aici. Dacă această metodă

returnează .T., apoi este apelată metoda DataSave, care este locul unde se va încerca salvarea efectivă și, în funcție de rezultat, fie metoda AfterSave, fie AfterFailSave este apelată pentru a gestiona orice procesare post-salvare specifică instanței.

Un set similar de metode se ocupă de procesul Revert, dar deoarece un TableRevert() nu poate „eșua” cu adevărat, avem nevoie doar de o singură metodă AfterRevert.

Metoda SaveForm

Codul real folosit în metodele SaveForm și RevertForm este de fapt identic, cu excepția numelor metodelor care urmează să fie apelate. Prin urmare, ar fi posibil să se apeleze o metodă de gestionare comună, „supraîncărcată”, cu un parametru care indică dacă este necesară acțiunea „Salvare” sau „Revenire”. Cu toate acestea, nu ne place foarte mult această abordare, deoarece face întreținerea mai dificilă și nu oferă cu adevărat niciun beneficiu tangibil. La urma urmei, un singur tip de acțiune va fi apelat în orice moment!

*** Această metodă include apelul la metoda DataSave

*** și include apeluri către Hooks Înainte și După

LPARAMETRI tcTables

LOCAL lcTables, llOk

CU ThisForm

*** Dacă nu trece nimic, presupuneți toate tabelele!

lcTables = IIF(VARTYPE( tcTables ) # "C" SAU EMPTY( tcTables ), .GetAllUsed(), tcTables )

DACĂ ! EMPTY(lcTables)

*** Apelați Hook „Înainte” la nivel de instanță

llOk = .BeforeSave(lcTables)

*** Dacă BeforeSave eșuează, codul pentru a gestiona eșecul trebuie plasat acolo

DACA Ok

*** Înainte a fost OK, așa că sunați principalul Salvare

llOk = .DataSave( lcTables )

DACA Ok

*** Toate au fost salvate, așa că apelați Hook „După” la nivel de instanță

.AfterSave( lcTables )

ALTE

*** Salvarea nu a reușit, așa că apelați Hook alternativ la nivel de instanță „După”.

.AfterFailSave( lcTables )

ENDIF

ENDIF

ALTE

*** Fără mese în uz, doar returnați .T.

llOk = .T.

ENDIF

SE TERMINA CU

Întoarce-te bine

Rezultatul acestei abordări este că acum putem codifica metoda DataSave special pentru a gestiona apelul efectiv la TableUpdate() deoarece am furnizat locații alternative pentru orice cod specific de instanță fie în metodele Before sau After și pentru că am codificat și funcționalitatea Revert. în propriul set de metode.

Un aspect discutabil este dacă aceste metode „înveliș” ar trebui să emită și o reîmprospătare la nivel de formular. În general, preferăm să nu facem acest lucru, deoarece tipul de reîmprospătare necesar poate depinde de rezultatele salvării și, prin urmare, ar trebui gestionat de codul specific al instanței fie în AfterSave, fie în AfterFailSave, după caz. Desigur, puteți alege să o faceți diferit.

Metoda DataSave

Codul real din această metodă este identic cu cel din DataRevert, cu excepția faptului că acesta din urmă apelează TableRevert(). Din nou, aceste două metode ar fi putut fi combinate într-o singură metodă, dar motivele pentru care nu au făcut acest lucru sunt aceleași.

Deși nu este încă discutat în acest capitol, veți observa că folosim o tranzacție aici. Vom avea mai multe de spus despre întreaga problemă a tranzacțiilor mai târziu, dar deocamdată acceptăm doar că folosim una pentru a ne asigura că actualizările sau reversurile multiple ale tabelului fie reușesc, fie eșuează, ca un bloc - la fel ca și cum am avea de-a face cu adevărat o singura masa:

LPARAMETRI tcTables

LOCAL llRetVal, lnCnt, IcToDo, lnBuffMode

CU ThisForm

*** Inițializați Valoarea de returnare la .T.

llRetVal = .T.

*** Începeți o tranzacție

ÎNCEPE TRANZACȚIA

*** Buclă prin toate tabelele

lnCnt = 0

FĂ CÂND .T.

*** Preluați numele tabelului

lnCnt = lnCnt + 1

lcToDo = .GetItem( tcTables, lnCnt )

*** Returul NULL indică sfârșitul șirului

IF ISNULL(lcToDo)

IEȘIRE

ENDIF

*** Verificați modul tampon al fiecăruia

lnBuffMode = .GetBufferMode( lcToDo )

*** Lansați comanda corectă de actualizare și „ȘI” rezultatul

FACE CAZ

CASE INLIST( lnBuffMode, 2, 3 )

*** Suntem Row Buffered

llRetVal = llRetVal ȘI TABLEUPDATE( 0, .F., lcToDo )

CASE INLIST( lnBuffMode, 4, 5 )

*** Suntem Table Buffered

llRetVal = llRetVal ȘI TABLEUPDATE( 1, .F., lcToDo )

IN CAZ CONTRAR

*** Fără buffering - așa că nu faceți nimic

ENDCASE

ENDDO

*** Angajați sau anulați tranzacția

IF llRetVal

Totul era bine

ÎNCHEIAȚI TRANZACȚIA

ALTE

*** Ceva n-a mers bine

ROLLBACK

ENDIF

SE TERMINA CU

*** Stare returnare

RETURN llRetVal

Folosind noua clasă de formulare

Exemplul de formular DemSave.scx ilustrează cum poate fi utilizată clasa de formulare descrisă. Am creat două clase noi de butoane (xCmdStdDisableSave și xCmdStdDisableUndó) bazate pe clasa noastră de butoane cu auto-dezactivare, care apelează doar metodele personalizate SaveForm sau RevertForm ale formularului din metodele lor OnClick. Deoarece aceste clase sunt destinate exclusiv utilizării cu un formular care are aceste metode, nu există niciun cod care să verifice dacă metoda există de fapt! De fapt, s-ar putea să fi adăugat aceste butoane direct în clasa formularului în sine, dar nu am făcut acest lucru, deoarece nu putem fi niciodată siguri că vom dori întotdeauna ambele butoane. (Amintiți-vă - nu puteți șterge un obiect care este definit de clasa părinte fie într-o subclasă, fie într-o instanță.) Acest lucru rezultă din afirmația noastră (vezi Capitolul 3) că, dacă funcționalitatea nu este în categoria „trebuie”, aceasta nu face parte din clasa!

Figura 8.4 Un formular folosind metodele generice Salvare/Anulare

În acest exemplu, metodele AfterSave, AfterFailSave și AfterRevert afișează pur și simplu un mesaj adecvat înainte de a apela o reîmprospătare la nivel de formular. Pentru a testa acest formular pur și simplu porniți două instanțe de VFP și deschideți tabelul demone în a doua instanță. După rularea formularului în prima instanță, efectuați și salvați o modificare a tabelului în a doua, apoi efectuați și salvați o modificare în aceeași înregistrare în formular.
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Detectarea și rezolvarea conflictelor

În secțiunile precedente, am văzut cum să detectăm modificări într-un tabel și cum să încercăm să actualizăm un tabel tamponat, așa că următoarea problemă este să ne asigurăm că modificarea propusă nu va provoca un conflict de actualizare atunci când este salvată. Una dintre problemele inerente cu utilizarea blocării optimiste într-un mediu multi-utilizator este că este posibil ca mai mult de un utilizator să facă modificări la aceeași înregistrare în același timp.

S-ar putea să vă întrebați de ce ar fi posibil așa ceva - cu siguranță doi utilizatori nu ar putea actualiza aceeași înregistrare în acel moment? În practică, există o mulțime de scenarii în care acest lucru se poate întâmpla în mod legitim. Luați în considerare situația într-un sistem de procesare a comenzilor de vânzare. Când se plasează o comandă pentru un articol, „stocul disponibil” actual trebuie ajustat pentru a reflecta reducerea. Dacă doi clienți, fiind manipulați de doi operatori simultan, includ același articol în comenzile lor, există șanse mari să apară un conflict. Evident, acest lucru nu se poate întâmpla dacă sistemul folosește blocarea pesimistă, dar asta are și alte consecințe, de obicei nedorite. În acest scenariu, cel de-al doilea operator care a încercat să acceseze elementul în cauză ar primi un mesaj că înregistrarea este utilizată de altcineva și nu va putea face modificări - nu de mare ajutor! În plus, blocarea pesimistă poate fi utilizată numai atunci când un tabel Visual FoxPro este utilizat direct ca sursă de date - nu puteți bloca în mod pesimist o vizualizare de orice fel.

Când se utilizează buffering, Visual FoxPro face o copie a tuturor datelor pe măsură ce sunt preluate din tabelul fizic și, atunci când este solicitată o actualizare, compară acest lucru cu starea curentă a datelor. Dacă nu există modificări, actualizarea este permisă, în caz contrar se generează eroarea de conflict de actualizare corespunzătoare (#1585 pentru Vizualizări, #1595 pentru tabele). Figura 8.5 ilustrează, schematic, cum funcționează acest lucru și cum este detectat un conflict de actualizare.

Figura 8.5 Actualizare schematică pentru tabelul tamponat
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Rolul OldVal() și CurVal()

Baza tuturor detectării conflictelor se află în două funcții native, „OLDVAL()” și „CURVALO”, care accesează cursoarele intermediare create de Visual FoxPro atunci când se utilizează date tamponate. După cum sugerează numele lor, oLDVALoripreluează valoarea unui câmp așa cum era când utilizatorul a citit ultima dată datele din sursă, în timp ce curvalo preia starea curentă a datelor din tabelul sursă. Ambele funcții operează la nivel de câmp și, deși ambele pot accepta o expresie care evaluează la o listă de câmpuri, ele sunt cel mai bine utilizate pentru a prelua valorile câmpurilor individual, pentru a evita problema rezolvării diferitelor tipuri de date.

Există o problemă! folosind curvalo pentru a verifica starea unei vizualizări. Visual FoxPro menține de fapt un nivel suplimentar de tamponare pentru o vizualizare care, cu excepția cazului în care vizualizarea este reîmprospătată imediat înainte de a verifica valoarea unui câmp, poate determina curbelo să returneze răspunsul greșit. Vom avea mai multe de spus despre funcția Refresh() și despre utilizarea acesteia, în secțiunea despre Vizualizări.
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Deci, cum detectez de fapt conflictele?

Înainte de a intra în discuția despre cum să detectăm un conflict, să fim clari care este definiția unui conflict de la Visual FoxPro. După cum sa indicat mai devreme, Visual FoxPro face două copii ale unei înregistrări ori de câte ori un utilizator accesează date. O copie este disponibilă ca cursor editabil și este locul în care un utilizator face modificări. Celălalt este păstrat în starea inițială. Înainte de a permite o actualizare să continue, Visual FoxPro compară acest cursor original cu datele stocate în prezent pe disc. Un conflict apare atunci când aceste două versiuni ale datelor nu se potrivesc exact și există două moduri în care acest lucru se poate întâmpla. Prima și cea mai evidentă este că utilizatorul actual face modificări unei înregistrări și încearcă să salveze acele modificări după ce altcineva a schimbat deja și a salvat aceeași înregistrare. Al doilea este puțin mai puțin evident și apare atunci când un utilizator nu face nicio modificare, ci încearcă să „salveze” o înregistrare pe care un alt utilizator a schimbat-o. Visual FoxPro va vedea în continuare acest lucru ca un conflict, deoarece valorile oldvalo și CURVAL () sunt de fapt diferite. Acest lucru este cel mai bine gestionat prin a nu face de fapt un TableUpdate() cu excepția cazului în care utilizatorul actual a făcut cu adevărat modificări, tocmai de aceea funcția IsChanged() este atât de utilă. Vă permite să determinați dacă este necesar un Tabieupdateo și să utilizați cod ca acesta în rutinele dvs. de salvare: llRetVal = .T.

IF IsChanged() llRetVal = TABLEUPDATE() ENDIF

RETURN llRetVal

Deci, evitând posibilitatea apariției conflictelor atunci când utilizatorul actual nu a făcut nicio modificare prin pur și simplu neîncercând să comite înregistrarea, există practic două strategii pe care le puteți adopta pentru a detecta conflictele. Prima o numim abordarea „Suge și vezi”. Acest lucru înseamnă pur și simplu că nu încercați să detectați potențiale conflicte, ci doar capturați rezultatul unei comenzi TableUpdate() și, atunci când nu reușește, luați pași pentru a afla de ce.

A doua este abordarea „Centură și bretele”, în care verificați fiecare câmp modificat și rezolvați conflictele înainte de a încerca să actualizați tabelul de bază. În timp ce acest lucru pare mai defensiv și, prin urmare, „mai bine”, există de fapt o problemă ascunsă cu el. În timpul necesar (deși foarte mic) pentru a verifica toate câmpurile modificate față de valorile lor curente, un alt utilizator poate reuși să schimbe chiar înregistrarea pe care o verificați. Deci, dacă nu blocați în mod explicit înregistrarea înainte de a începe să verificați valorile, actualizarea reală ar putea eșua. Întrucât vrem cu adevărat să evităm plasarea încuietorilor în mod explicit, trebuie să încorporați exact aceeași verificare a rezultatului comenzii TableUpdate() și să oferiți aceeași gestionare a eșecului de care aveți nevoie în strategia mult mai simplă „suge-l și vezi” !

Prin urmare, cu excepția cazului în care aveți un motiv primordial pentru prevalidarea modificărilor, vă recomandăm insistent să lăsați Visual FoxPro să detecteze conflictele și să capteze și să gestioneze astfel de erori pe măsură ce apar. Indiferent de strategia pe care o alegeți, veți avea totuși nevoie de unele mijloace pentru a găsi câmpurile dintr-o anumită înregistrare, astfel încât să puteți obține valorile adecvate de la тою și oidvaio. Următoarea funcție, GetUserChanges(), returnează o listă de câmpuri separate prin virgulă care au fost modificate de utilizatorul curent:

**************************************************** ********************

* 	Program. GetUserChanges.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Returnează o listă separată de virgulă cu câmpurile care au fost modificate

* 	..........:de către utilizator în rândul curent al tabelului specificat

**************************************************** ********************

LPARAMETRI tcTable

LOCAL lcTable, lcRetVal, lnBuffMode, lcFldState, lnCnt, lcStatus

*** Verificați parametrul, presupuneți aliasul curent dacă nu a trecut nimic

lcTable = IIF( VARTYPE(tcTable) # "C" SAU EMPTY( tcTable ), ;

ALIAS(), ALLTRIM( UPPER( tcTable )))

*** Verificați dacă numele tabelului specificat este folosit ca alias

DACĂ GOL (lcTable) SAU ! FOLOSIT( JUSTSTEM( lcTable) )

*** Eroare - probabil o eroare de dezvoltator, așa că utilizați o eroare pentru a o raporta!

EROARE „9000: GetUserChanges() necesită aliasul unui tabel deschis” ;

+ CHR(13) + "să fie trecut sau ca zona de lucru actuală să" ;

+ „conține un” + CHR.(13) + „deschideți masa”

RETURNARE .F.

ENDIF

lcRetVal = ''

*** Verificați starea tamponării

lnBuffMode = CURSORGETPROP( 'Buffering', lcTable )

IF lnBuffMode = 1

*** Nu este stocat în tampon, deci nu pot fi „modificări în așteptare”

RETURN lcRetVal

ENDIF

*** Dacă ajungem atât de departe, avem o înregistrare tampon care POT avea modificări

*** Așadar, verificați câmpurile care au modificat valorile

lcFldState = NVL( GETFLDSTATE( -1, lcTable ), "")

DACĂ EMPTY( CHRTRAN( lcFldState, '1', ''))

*** Nimic în afară de „1”, prin urmare nimic nu s-a schimbat

RETURN lcRetVal

ENDIF

*** Deci, avem cel puțin un câmp schimbat! Dar trebuie să ne ocupăm de

*** Indicatorul steag șters primul. Putem folosi „DELETED()” ca nume de câmp aici!

DACĂ ! INLIST(LEFT(lcFldState, 1), „1”, „3” )

lcRetVal

ȘTERS()

ENDIF

*** Acum scăpați de indicatorul steag șters

lcFldState = SUBSTR( lcFldState, 2 )

*** Obțineți numele câmpurilor pentru câmpurile modificate

FOR lnCnt = 1 TO FCOUNT()

*** Buclă prin câmpuri

lcStatus = SUBSTR( lcFldState, lnCnt, 1 )

IF INLIST(lcStatus, „2”, „4” )

lcRetVal = lcRetVal + IIF( ! EMPTY(lcRetVal ), ",", "") + FIELD( lnCnt )

ENDIF

URMĂTORUL

*** Returnează lista câmpurilor modificate

RETURN lcRetVal

Observați că folosim funcția nativă DELETED() ca nume de câmp în această funcție. Atât CurVal() cât și oldval() vor accepta acest lucru ca un „nume de câmp” valid (returnând o valoare logică care indică dacă câmpul a fost șters în tabelul de bază), astfel încât să putem verifica efectiv ștergeri, precum și modificări.

Având o listă de câmpuri care s-au schimbat, putem folosi o funcție precum GetItem() (una dintre procedurile noastre generice, descrisă în Capitolul 2) pentru a prelua numele câmpurilor individuale, dacă este necesar. Valorile originale și curente pentru fiecare câmp modificat pot fi apoi preluate și comparate pentru a determina unde apar conflictele. Exemplul de program ListFields.prg ilustrează modul în care funcționează și listează pe ecran valoarea reală, CurVal() și OldVal() pentru modificările aduse unuia dintre tabelele demonstrative. Iată codul:

**************************************************** ********************

* 	Program. ListFields.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Ilustrați utilizarea GetUserChanges(), GetItem(), CurVal() și OldVal()

**************************************************** ********************

LOCAL lcChgFlds, lnCnt, lcCurFld

*** Deschideți fișierul Procedură

SETĂ PROC LA CH08 ADITIV

*** Deschide un tabel și tamponează-l

USE demone

CURSORSETPROP(„Buffering”, 5, „demone”)

*** Faceți câteva modificări

ÎNLOCUIȚI dlName CU „William”, dlCity CU „WallHouse”

*** Obțineți lista câmpurilor modificate

lcChgFlds = GetUserChanges('demone')

*** Afișează rezultatele

lnCnt = 0

FĂ CÂND .T.

*** Preluați numele câmpului

lnCnt

lnCnt + 1

lcCurFld = GETITEM( IcChgFlds, lnCnt )

*** Returul NULL indică sfârșitul șirului

IF ISNULL(lcCurFld)

IEȘIRE

ENDIF

*** Afișați numele câmpului

? „Nume câmp: „ + CHR(9)

?? lcCurFld

*** Afișați valoarea curentă

? „Valoarea reală a câmpului” + CHR(9)

?? &lcCurFld

*** Valoarea curentă a discului

? „Valoare CURVALO” + CHR(9)

?? CURVAL(lcCurFld, 'demone' )

*** Valoarea originală

? „Valoare OLDVAL()” + CHR(9)

?? OLDVAL(lcCurFld, 'demon' )

ENDDO

*** Pierdeți modificări

TABLEREVERT( .T., „demon”)

ÎNCHID MABELE TOATE
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OK, atunci, după ce am detectat un conflict de actualizare, ce pot face în privința acestuia?

Există patru strategii de bază pentru gestionarea conflictelor de actualizare. Puteți alege unul sau combina mai multe într-o aplicație, în funcție de situația reală:

[1] 	Utilizatorul actual câștigă întotdeauna: această strategie este adecvată numai în acele situații în care utilizatorul care încearcă de fapt să salveze este unul ale cărui date se consideră a fi cele mai precise. De obicei, acest lucru ar fi implementat pe baza ID-ului utilizatorului care realizează salvarea și ar implementa o regulă de afaceri conform căreia informațiile anumitor persoane sunt mai valoroase decât altele.

Un exemplu ar putea fi într-o aplicație TeleSales în care un operator care vorbește cu clientul ar putea avea drepturi de înlocuire la informațiile de contact ale clientului (pe baza faptului că persoana care vorbește efectiv cu clientul este cel mai probabil să poată obține detaliile corecte). Conflictele pot apărea în această situație când un administrator actualizează detaliile unui client din datele din dosar sau din ultima comandă, în timp ce un operator primește noi detalii direct de la client.

Implementarea acestei strategii în Visual FoxPro este într-adevăr foarte simplă. Pur și simplu setați parametrul „FORCE” (al doilea) din funcția TableUpdate() la „.T” și retrimiteți actualizarea.

[2] 	Utilizatorul actual pierde întotdeauna: acesta este exact inversul situației de mai sus. Utilizatorului actual îi este permis să salveze modificări numai cu condiția ca niciun alt utilizator să nu fi făcut modificări. Din nou, acest lucru ar fi implementat în mod normal pe baza unui ID de utilizator și ar reflecta probabilitatea ca acest utilizator să lucreze din informații „istorice”, mai degrabă decât „actuale”.

Implementarea în Visual FoxPro este, de asemenea, foarte simplă. Modificările utilizatorului curent sunt anulate, datele sursă sunt interogate din nou, iar utilizatorul trebuie să facă din nou toate modificările necesare. Aceasta este probabil strategia care este adoptată cel mai des - dar de obicei pe o bază generală!

[3] 	Utilizatorul actual câștigă uneori: această strategie este cea mai complexă dintre cele patru de implementat, dar este de fapt destul de comună. Principiul de bază este că atunci când apare un conflict de actualizare, determinați dacă vreunul dintre câmpurile pe care utilizatorul curent le-a modificat va afecta modificările efectuate de celălalt utilizator. Dacă nu, înregistrarea utilizatorului curent este actualizată automat (folosind valorile curvalo), astfel încât cauza conflictului este anulată și actualizarea este apoi retrimisă. Cu toate acestea, deoarece nu puteți modifica valorile returnate de oidvaio, trebuie să forțați această a doua actualizare.

De altfel, această strategie abordează și problema modului de gestionare a unui conflict de actualizare „fals pozitiv”. Acest lucru se întâmplă atunci când există o discrepanță între valorile de pe disc și cele din buffer-ul utilizatorului curent, dar modificările utilizatorului actual nu intră în conflict cu niciuna dintre modificările efectuate. În mod clar, această situație nu este cu adevărat un conflict, dar trebuie gestionată.

Deși nu este trivială, implementarea în Visual FoxPro este relativ ușoară. În primul rând, funcția curvalo este utilizată pentru a determina cum să actualizezi memoria tampon al utilizatorului curent, astfel încât să nu suprascrie modificările făcute.

de către alt utilizator. Apoi actualizarea este aplicată folosind parametrul forță (al doilea) din таыелдоо pentru a spune Visual FoxPro să ignore conflictul care va apărea deoarece OldVal() și CurVal() nu corespund.

[4] Utilizatorul actual decide: Acesta este scenariul „Prin toate”. Conflictul nu se încadrează în nicio regulă de afaceri recunoscută, așa că singura soluție este să întrebați utilizatorul a cărui acțiune de salvare a declanșat conflictul ce dorește să facă în privința acestuia. Ideea de bază aici este că îi prezentați utilizatorului care a declanșat conflictul cu o listă de valori - cea pe care tocmai a introdus-o, valoarea care era în tabel (adică cea pe care tocmai a schimbat-o) și valoarea care se află acum în tabelul (adică cel la care altcineva a schimbat valoarea inițială). Utilizatorul poate decide apoi dacă forțează sau anulează propriile modificări.

Instrumentele de bază pentru implementarea acestei strategii au fost deja discutate în secțiunea precedentă. Tot ceea ce este necesar este să se determine care câmpuri sunt într-adevăr în conflict și să le prezinte utilizatorului în așa fel încât utilizatorul să poată decide, câmp cu câmp, ce să facă în privința conflictelor. În practică, această strategie este de obicei combinată cu Strategia [3] de mai sus, astfel încât utilizatorului i se prezintă doar o listă de câmpuri în care există de fapt un conflict în câmpurile pe care le-au modificat.
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Rezolvarea conflictelor sună bine în teorie, cum funcționează în practică?

Există multe modalități de implementare a soluționării conflictelor. Metoda cea mai potrivită va depinde de cerințele aplicației dvs. Cu toate acestea, pentru a ilustra modul în care l-ați putea implementa, am creat o clasă numită „UpdRes” (în biblioteca UpdRes.vcx). Acesta constă într-un formular, care are metode pentru a crea și a popula un cursor local cu cele trei valori necesare pentru toate câmpurile care provoacă un conflict. Implementează o combinație a strategiilor „Utilizatorul actual Câștigă uneori” și „Utilizatorul actual decide” (Figura 8.6).

Figura 8.6 O clasă de afișare simplă pentru rezolvarea conflictelor

Formularul arată utilizatorului câte conflicte au fost detectate și afișează, pentru fiecare câmp conflictual, valorile din OLDVAL()? CURVALO și tamponul curent. În mod implicit, toate conflictele sunt semnalate pentru rezolvare prin anularea modificării utilizatorului curent și un grup de opțiuni simplu permite utilizatorului să suprascrie modificarea existentă câmp cu câmp. O rafinare suplimentară este opțiunea „FORȚARE TOATE” care stabilește toate conflictele să fie rezolvate folosind valorile utilizatorului curent. Când utilizatorul este mulțumit, făcând clic pe butonul de ieșire se vor aplica modificările specificate în tabel.

Metoda Init

Clasa este configurată ca formă modală și se așteaptă să primească doi parametri - numărul DataSession al formularului care a numit-o și numele tabelului din acea sesiune de date care a provocat conflictul. Codul de aici pur și simplu setează formularul în sesiunea de date corectă și apoi calizează metodele SetUpForm și CheckUpdates:

LPARAMETERS tnDSID, tcTable

LOCAL LlRetVal

CU ThisForm

*** Setați acest formular pe cel transmis în DataSession

.DataSessionID = tnDSID

*** Închideți cursorul și legați câmpurile la acesta

.SetUpForm()

*** Rulați metoda CheckUpdates() pentru tabelul specificat

llRetVal = .CheckUpdates( tcTable )

RETURN llRetVal

SE TERMINA CU

Metoda CheckUpdates returnează o valoare logică care indică dacă există de fapt conflicte care necesită intervenția utilizatorului și, deoarece această valoare este returnată de metoda Class Init, va împiedica instanțiarea clasei atunci când nu există conflicte care nu pot fi rezolvate programatic. Codul de apelare pentru această clasă trebuie, prin urmare, să ia în considerare această posibilitate.

Metoda SetUpForm

Acest lucru este extrem de simplu și doar creează cursorul local și setează controalele formularului să folosească acest cursor ca sursă de control. Acest lucru trebuie făcut fie în Init, fie într-o metodă numită din Init, deoarece trebuie să introducem formularul în sesiunea de date corectă înainte de a crea cursorul. Deoarece ID-ul DataSession necesar este transmis ca parametru, nu îl putem accesa în nicio metodă înainte de inițializarea propriei formulare:

CU ThisForm

*** Creați un cursor local pentru stocarea conflictelor

CREATE CURSOR curcflix ( ;

cfxRecNum C ( 8), ; && Numărul conflictului

cfxFldNam C (200), ; && Numele domeniului

cfxOldVal C (200),; && Valoarea originală

cfxCurVal C (200),; && Valoarea curentă pe disc

cfxUsrVal C (200),

; && Modificare în tampon

cfxForcit N ( 1) ) && Acțiune definită de utilizator

*** Leagă Comenzile la acesta

.TxtRecNum.ControlSource = "curcflix.cfxRecNum"

.txtFldNam.ControlSource = "curcflix.cfxFldNam"

.txtOrgVal.ControlSource = „curcflix.cfxOldVal”

.txtCurVal.ControlSource = "curcflix.cfxCurVal" .txtNewVal.ControlSource = "curcflix.cfxUsrVal" .OptUsrChoice.ControlSource = "curcflix.cfxforcit" .Refresh()

SE TERMINA CU

RETURNARE .T.

Metoda CheckUpdates

Aici se realizează o parte din munca reală a clasei. Prima parte a codului se referă la asigurarea că tabelul corect este disponibil, selectat și apoi determină ce tamponare folosește:

LPARAMETERS tuTable

LOCAL llRetval, lnBuffMode, lcTable, lnOldArea, lnNextRec, lnRows

*** Verificați parametrii

IF EMPTY(tuTable)

*** Nu a trecut nimic, folosiți tabelul curent

lcTable = ALLTRIM( ALIAS() )

IF EMPTY( lcTable )

*** Fără masă

RETURNARE .F.

ENDIF

ALTE

FACE CAZ

TIP CAZ ("tuTable" ) = "C"

*** Să presupunem că șirul de caractere este aliasul necesar

lcTable = ALLTRIM( tuTable)

TIP CAZ ("tuTable" ) = "N"

*** Obțineți aliasul pentru zona de lucru specificată

lcTable = ALIAS( tuTable )

IN CAZ CONTRAR

*** Parametru nevalid - ieșire cu eroare

RETURNARE .F.

ENDCASE

ENDIF

*** Verificați BufferMode

llRetVal = .T.

lnBuffMode = CURSORGETPROP( 'Buffering', lcTable )

IF lnBuffMode < 2

*** Dacă tabelul nu este tamponat, trebuie să reveniți

RETURNARE .F.

ALTE

*** Salvați zona de lucru curentă și selectați tabelul necesar

lnOldArea = SELECT()

SELECTARE (lcTable)

ENDIF

Următoarea parte a metodei depinde de modul de tamponare care este utilizat. Dacă Table Buffering este în vigoare, metoda CheckRec este apelată o dată pentru fiecare rând în care au fost detectate modificări pentru a popula cursorul de conflict dacă este necesar. Dacă este utilizată tamponarea rândurilor, este necesar doar un singur apel.

*** Trebuie să gestionați diferit Row Buffering și Table Buffering

CU ThisForm

*** Setați subtitrarea formularului și stocați tabelul țintă la o proprietate Form

*** Pentru utilizare în metoda DoUpdates().

.caption = "Actualizați conflictele în tabel: " + lcTable

.cTarget = ALIAS()

*** Verificați modul de tamponare

IF lnBuffMode < 4

*** Row Buffering

llRetVal = .ChkRec( RECNO(), lcTable )

ALTE

*** Table Buffering - trebuie să găsiți toate înregistrările modificate

lnNextRec = 0

FĂ CÂND .T.

InNextRec = GETNEXTMODIFIED( InNextRec )

DACĂ InNextRec = 0

IEȘIRE

ENDIF

*** Încercați să actualizați înregistrarea

llRetVal = .ChkRec( lnNextRec, lcTable )

DACĂ ! llRetVal

*** Dacă nu a reușit, ieșiți

IEȘIRE

ENDIF

ENDDO

ENDIF

Secțiunea finală a codului verifică doar numărul de înregistrări al cursorului de conflict pentru a vedea dacă utilizatorul trebuie să facă ceva. Dacă nu, se face un Taweopdateo forțat pe toate înregistrările pentru a șterge tamponul:

*** Verificați cursorul de conflict

DACĂ RECCOUNT( „curcflix”) = 0

*** Nu există conflicte de nerezolvat, așa că forțați actualizarea

*** Prin întoarcerea .F. la Init() împiedicăm instanțiarea obiectului

*** și utilizatorul nu va vedea nimic!

llRetVal = ! TabelUpdate( .T., .T. )

ALTE

MERGE TOP ÎN curcflix

ENDIF

SE TERMINA CU

*** Faceți ordine

SELECTAȚI (lnOldArea)

RETURN llRetVal

Metoda ChkRec

Această metodă este apelată o dată pentru fiecare rând care trebuie validat și este locul în care se ia decizia dacă este necesară sau nu intervenția utilizatorului. Pentru rândurile în care un conflict nu poate fi rezolvat programatic, o înregistrare pentru fiecare câmp care necesită intervenția utilizatorului este inserată în cursorul de conflict:

LPARAMETERS tnRecNum, tcTable

LOCAL lnCnt, luCurVal, luOldVal, lnRows, llRetVal, lcFldList, lcFldName, luUsrVal

*** Forțați înregistrarea corectă să fie actuală

SELECTARE (tcTable)

IF RECNO() # tnRecNum

GOTO tnRecNum

ENDIF

*** Obțineți lista câmpurilor modificate de utilizatorul curent

lcFldList = ""

lcFldList = ThisForm.GetUserChanges( tcTable )

*** Scanați prin câmpuri

FOR lnCnt = 1 TO FCOUNT()

lcFldName = CÂMP (lnCnt)

luCurVal = CURVAL( CÂMP( lnCnt ))

luOldVal = OLDVAL( FIELD( lnCnt ))

luUsrVal = EVAL( FIELD( lnCnt ))

*** Acest câmp va provoca un conflict?

IF luCurVal == luOldVal

*** Nu s-au făcut modificări în câmp

*** Deci nu va apărea nicio problemă

BUCLĂ

ENDIF

*** Au fost făcute modificări în domeniu

DACĂ ! FIELD( lnCnt ) $ lcFldList

*** Dar utilizatorul curent nu a modificat câmpul

*** Așa că putem să-l actualizăm din CurVal()

ÎNLOCUIRE (CÂMP(lnCnt)) CU luCurVal

ALTE

*** Ceva s-a schimbat! Întrebarea este CE?

IF EVAL( FIELD(lnCnt) ) == luCurval

*** Utilizatorul nu a schimbat de fapt nimic

BUCLĂ

ALTE

*** Acesta este un conflict pe care nu îl putem rezolva programatic

*** Adăugați-l la Cursorul de conflict

CU ThisForm

INSERT INTO curcflix ;

( cfxRecNum, ;

cfxFldNam, ;

cfxOldVal, ;

cfxCurVal, ;

cfxUsrVal, ;

cfxForcit);

VALORI ;

( .ExpToStr(RECNO()), ; lcFldName, ;

.ExpToStr(luOldVal), ;

.ExpToStr(luCurVal), ;

.ExpToStr(luUsrVal), ;

2)

SE TERMINA CU

ENDIF

ENDIF

URMĂTORUL

Pentru fiecare câmp din înregistrare, această metodă citește valoarea tamponată a utilizatorului curent, valorile Olialo și Curval() și le trece printr-o verificare logică, după cum urmează:

DACĂ utilizatorul nu a modificat acest câmp, iar valorile Vechi și Actual sunt identice,

ignora acest câmp

ALTE

DACĂ utilizatorul nu a modificat câmpul, dar valorile Vechi și Actual sunt diferite,

actualizați tamponul direct cu valoarea curentă

ALTE

DACĂ utilizatorul a schimbat câmpul, dar valoarea din buffer este deja identică

la valoarea curentă, ignorați această modificare

ALTE

Acesta este într-adevăr un conflict, așa că inserați un rând în cursorul de conflicte

Rețineți că această metodă folosește funcția GetUserChanges discutată mai sus, deși, deoarece aceasta este o clasă, codul a fost adăugat (neschimbat) ca metodă. Aceeași logică se aplică dublării aparente a funcțiilor ExpToStr și StrToExp (pe care le-am introdus în Capitolul 2) ca metode. Această clasă depinde de datele care sunt tratate într-un mod specific și nu trebuie să se bazeze pe nimic în afara ei. Dacă ar fi să ne bazăm pe faptul că aceste funcții sunt disponibile într-un fișier de procedură, am sparge încapsularea clasei și ne-am lăsa deschiși la potențiale probleme dacă procedurile externe ar fi modificate.

Pentru a vedea această clasă în acțiune pur și simplu rulați programul ShowConf.prg inclus în exemplul de cod pentru acest capitol. Acest program creează două instanțe ale unui formular de date simplu (vezi Figura 8.7). Efectuați unele modificări la o instanță a formularului, apoi, fără să faceți clic pe SALVARE, comutați la cealaltă instanță și mai faceți și SALVați câteva modificări. Făcând clic pe SALVARE în prima formă va invoca acum ecranul de rezolvare a conflictelor, presupunând întotdeauna că modificările pe care le-ați făcut în cealaltă instanță au cauzat unul sau mai multe conflicte.

Actualizați Rezolvarea conflictelor Exarnpk- [Utilizator 1)

Personaj Field Dave

Câmpul Memo

Câmp numeric

Câmp întreg

Câmp de dată

Câmpul DateTime

Aceasta este o schimbare în curs

Câmp logic |7 Casetă de verificare

Skip On Skip Back

Salvați 	EXIT

Actualizare exemplu de rezolvare a conflictelor (utilizator 2)



Câmpul de caractere

Andy

Câmpul Memo

Câmp numeric

200.00

Această modificare a fost salvată

Câmp întreg

100

Câmp de dată

10/01/1999

Câmp DateTime

Câmp logic

110/01/1999 09:30:00

|7 Casetă de verificare

Skip On J 	Salt înapoi |Salvare 1EXIT J

Figura 8.7 Forțarea conflictelor de actualizare

Codul care invocă ecranul de rezolvare a conflictelor este conținut (în scopul acestei demonstrații) în metoda de clic a butonului Salvare din formular. Este necesar foarte puțin cod, după cum urmează:

*** Selectați tabelul principal

SELECT (Acest formular. Tabel primar)

*** Încercați și actualizați

110k = TABLEUPDATE()

*** Dacă actualizarea eșuează, creați obiectul de rezolvare a conflictelor

DACĂ ! 110k

oUpd = CREATEOBJECT('updres', ThisEorm.DataSessionID, ALIAS() )

*** Dacă obiectul există, ESTE un conflict real, arată fonem

IF TYPE ( OUpd' ) = "O" ȘI ! ISNITLL(oUpd)

oUpd.Show()

ENDIF

ENDIF

Amintiți-vă - modul în care este construită clasa de rezolvare a conflictelor asigură că obiectul persistă doar atunci când este detectat un conflict care nu poate fi rezolvat programatic. Această abordare asigură că utilizatorul vede un conflict doar atunci când există într-adevăr unul care are nevoie de intervenție pozitivă - orice altceva este gestionat transparent.
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Utilizarea tranzacțiilor

O tranzacție în Visual FoxPro oferă un strat suplimentar de buffering care poate cuprinde modificări la mai multe tabele (spre deosebire de tamponarea „normală”, care este specifică tabelului). Cu toate acestea, nu există opțiuni pentru controlul acestui strat suplimentar. Pentru orice tranzacție este fie „totul, fie nimic”, deși puteți imbrica tranzacții de până la cinci niveluri adânci, iar astfel de tranzacții imbricate sunt derulate pe baza „Ultimul intrat, primul ieșit”. Funcția principală a unei tranzacții este de a asigurați-vă că, atunci când modificările aduse mai multor tabele depind de succesul celuilalt, nicio modificare nu este făcută niciunui tabel, cu excepția cazului în care se pot face și toate actualizările asociate.

O Tranzacție este inițiată cu o comandă „Începeți Tranzacția și este încheiată fie printr-o comandă „Încheierea Tranzacției” („Commit”), fie printr-o comandă „Retroducere”. Totuși, acestea sunt comenzi separate și nu constituie o „Structură de control” (cum ar fi if..flse..fndif sau do case.endcase). Nu există nicio cerință ca comanda de închidere să fie în aceeași metodă (sau chiar în același program) ca și comanda de inițiere, singura regulă este ca fiecare comandă Begin Transaction să fie încheiată corect undeva. Cu toate acestea, este cu siguranță mai ușor să citiți și să vă întrețineți codul atunci când codul de gestionare a tranzacțiilor este păstrat într-un singur loc.

Restricții și limitări

Visual FoxPro controlează și gestionează tranzacțiile prin intermediul DBC, prin urmare tabelele gratuite nu pot participa la o tranzacție, deși o singură tranzacție poate include tabele din mai multe baze de date.

În timp ce o tranzacție este activă, toate înregistrările (din toate tabelele) care participă la tranzacție sunt complet blocate - nu puteți nici să citiți, nici să scrieți în aceste înregistrări! Din acest motiv, este imperativ ca, în aplicațiile multi-utilizator, tranzacțiile să fie active doar pentru un timp cât mai scurt posibil.

În cele din urmă, comenzile care schimbă starea unui tabel (spre deosebire de datele acestuia) nu pot fi utilizate în cadrul unei tranzacții. O listă completă a acestora poate fi găsită în fișierul de ajutor sub subiectul „Începeți tranzacția”. Rețineți în special că funcțiile CursorSetProp() și TableRevert() nu sunt acceptate în timp ce o tranzacție este activă.

Când am nevoie de o tranzacție?

Singurul moment în care trebuie cu adevărat să utilizați o tranzacție este atunci când manipulați date care, deși sunt stocate în tabele diferite, sunt interdependente. De exemplu, într-o aplicație de gestionare a stocurilor nu ați dori de fapt să actualizați stocul gratuit al unui articol dacă linia de comandă pentru acel articol nu ar putea fi salvată dintr-un motiv oarecare. Deși destul de separate, aceste două acțiuni sunt în mod clar legate între ele și ar trebui tratate ca și cum ar fi într-adevăr o singură operațiune. Astfel, dacă comanda poate fi plasată, stocul trebuie actualizat, dar dacă comanda nu poate fi plasată, atunci stocul nu trebuie actualizat.

Este perfect posibil să scrieți cod care obține rezultatul necesar (și multe sisteme scrise în versiunile anterioare ale FoxPro au un astfel de cod), dar nu este un exercițiu banal. O tranzacție ne oferă posibilitatea de a gestiona toate problemele cu un cod foarte simplu, cum ar fi acesta:

ÎNCEPE TRANZACȚIA

LOCAL llOk

llOk = TABLEUPDATE( 2, .F., „Linii de comandă”, laEșuat )

DACA sunt OK

*** Liniile au fost actualizate OK, acum faceți stocul

llOk = TABLEUPDATE( 2, .F., „FreeStock”, laEșuat )

ALTE

*** Gestionați aici erorile de actualizare a articolului de comandă

ENDIF

DACA sunt OK

*** Tot în regulă, deci comite modificările

ÎNCHEIAȚI TRANZACȚIA

ALTE

*** Ceva a eșuat, așa că anulați totul

ROLLBACK

ENDIF

Ce efect are rollback-ul asupra datelor mele?

Răspunsul scurt aici este niciunul! Obiectivul unei tranzacții este de a se asigura că fie toate modificările sunt comise, fie că niciuna nu se efectuează. Prin urmare, în cazul unei tranzacții eșuate, tabelele ar trebui să fie exact în aceeași stare în care se aflau înainte de inițierea tranzacției. Rollback nu este același lucru cu un TableRevert() și nu schimbă starea inițială a niciunei date. Cu toate acestea, dacă ați făcut modificări la datele din cadrul tranzacției, atunci orice astfel de modificări vor fi anulate ca parte a retragerii. Următorul cod poate fi rulat din linia de comandă pentru a vedea cum funcționează:

USE demone

CURSORSETPROP( „Buffering”, 5 )

ÎNCEPE TRANZACȚIA

NAVIGA

ÎNLOCUIȚI TOATE Dlcity CU „Londra”

Rețineți că acest lucru schimbă, de fapt, toate datele. Nu există restricții privind modificarea datelor în interiorul unei tranzacții, deși nu puteți modifica starea unui tabel (modul său de stocare în tampon, indici și așa mai departe). Puteți chiar să utilizați TableUpdate() pentru a „confirma” modificările:

? TABLEUPDATE( 2, .F., „demone”)

se pare că va confirma modificările, așa cum se arată prin faptul că un SQL Select poate acum „vede” modificarea:

SELECTAȚI DISTINCT dlCity FROM demone ÎN CURSOR cur_city NOFILTER

acum vă oferă un singur rând cu „Londra” ca singur oraș. Cu toate acestea, deși actualizate, modificările nu sunt încă „comite” și pot fi anulate prin anularea tranzacției:

ROLLBACK

SELECTAȚI DISTINCT dlCity FROM demone ÎN CURSOR cur_city NOFILTER

Reluarea interogării returnează lista originală de orașe ca și cum nimic nu s-ar fi întâmplat.

Hei, asta înseamnă că pot folosi o tranzacție pentru a activa SQL pentru a vedea modificările „în așteptare”?

Răspunsul scurt este DA! O interogare SQL își primește în mod normal datele din tabelul de bază, așa că nu puteți utiliza SQL pentru a verifica ceva pe care un utilizator a introdus sau modificat într-un tabel tampon până când modificarea a fost salvată folosind un TableUpdate(). Cu toate acestea, Visual FoxPro verifică întotdeauna datele care sunt stocate în memoria cache în buffer-ul de tranzacții înainte de a recurge la cele stocate pe disc pentru interogări pe tabelele implicate în tranzacții. Deci, prin includerea TableUpdate() într-o tranzacție, puteți actualiza „temporar” un tabel, puteți rula SQL-ul și apoi puteți anula modificările.

Există, desigur, un cost aici (la urma urmei, nimic nu este cu adevărat gratuit!). Trebuie să vă amintiți întotdeauna că o tranzacție blochează alți utilizatori în înregistrările implicate - astfel încât regula de aur atunci când utilizați o tranzacție este întotdeauna să o mențineți activă pentru un timp cât mai scurt posibil. Nu vă recomandăm să folosiți această tehnică pentru cantități mari de date sau interogări complexe, dar poate fi foarte eficientă atunci când este utilizată pentru operațiuni cu un singur tabel (cum ar fi însumarea unui set de valori afișate într-o grilă de editare).

Cum afectează o tranzacție mecanismele de blocare ale FoxPro?

La cel mai simplu nivel, răspunsul este că o tranzacție are un efect redus asupra modului în care Visual FoxPro gestionează plasarea lacătelor. Cu alte cuvinte, de fiecare dată când se solicită un blocaj fie implicit, fie explicit, acesta va fi plasat. Multe comenzi Visual FoxPro solicită o blocare „implicită”. (O listă completă a acestor comenzi, împreună cu tipul de blocare pe care le plasează, poate fi găsită în Ghidul programatorului, Capitolul 17 „Programare pentru acces partajat.”) Ori de câte ori una dintre aceste comenzi este utilizată în cadrul unei tranzacții, Visual FoxPro eliberează blocarea. locuri la încheierea tranzacției.

Blocările care sunt plasate în mod explicit (folosind rlocko sau flocko) sunt respectate de tranzacții și, prin urmare, trebuie, de asemenea, eliberate în mod explicit prin comanda de deblocare corespunzătoare. Cu toate acestea, trebuie să spunem că, în general, găsim puțină utilizare pentru blocarea explicită în Visual FoxPro. Dacă utilizați tabele și tranzacții tamponate (și de ce nu ați fi?), cel mai bun și mai sigur mod de a gestiona blocarea în interiorul unei tranzacții este să lăsați Visual FoxPro să o facă pentru dvs.

Am inteles! Blocările automate nu sunt întotdeauna lansate în Visual FoxPro Versiunea 5.0

Un cuvânt de precauție dacă utilizați versiunea 5.0 - există o eroare care poate cauza probleme dacă utilizați comenzi care plasează blocări automate de fișiere într-o tranzacție. Aceste blocări NU sunt eliberate când tranzacția se încheie. Următorul cod arată problema:

*** Deschide o masă

USE <tabel>

*** Setați tamponarea tabelului

CURSORSETPROP( „Buffering”, 5 )

*** Începeți o tranzacție

ÎNCEPE TRANZACȚIA

*** Utilizați o comandă care solicită o blocare a fișierului

ÎNLOCUIȚI TOATE <câmpul> CU <testval> PENTRU <condiție>

*** Verificați starea de blocare

? ISFLOCKED() && .F.

*** Actualizați tabelul

TABLEUPDATE(.T.) && .T.

*** Verificați starea de blocare

? ISFLOCKED() && .T.

*** Finalizați Tranzacția

ÎNCHEIAȚI TRANZACȚIA

*** Verificați starea blocării - fișierul este ÎNCĂ blocat

? ISFLOCKED() && .T.

Acest lucru poate fi, într-un mediu cu mai mulți utilizatori, o problemă majoră atunci când trebuie să faceți actualizări blocate pe tabelele implicate în relații unu-la-mai multe. Din fericire, există o soluție simplă prin utilizarea unui SCAN.ÆNDSCAN cu o înlocuire explicită pentru rândurile corespunzătoare în loc de un REPLACE ALL. Și mai din fericire, această problemă a fost rezolvată în versiunile ulterioare ale Visual FoxPro.

Pot folosi mai multe tranzacții simultan?

Da, tranzacțiile în prezent pot fi imbricate până la cinci niveluri adânci, iar funcția TXNLEVEL() poate fi utilizată pentru a determina numărul de tranzacții deschise. Cu toate acestea, tranzacțiile imbricate sunt întotdeauna lansate pe baza Last-In First Out, astfel încât logica trebuie construită cu atenție pentru a evita închiderea greșită a celei greșite - mai ales dacă codul de control este conținut în mai multe metode (sau proceduri). Cu condiția ca secvențierea să fie gestionată corect, nu este mai dificil să folosești mai multe tranzacții decât să folosești una singură.

Tranzacțiile multiple sunt utilizate la actualizarea tabelelor care formează grupuri logice, dar care nu trebuie tratate toate ca o singură unitate. Deoarece nu putem controla evenimentele din interiorul unei tranzacții la un nivel mai mare de granularitate decât tranzacția în sine, singura modalitate de a gestiona astfel de cazuri este prin imbricarea tranzacțiilor subgrup într-o tranzacție principală sau „înveliș”. De exemplu, luați în considerare adăugarea unui client nou și prima comandă a acestuia la un set tipic de tabele.

În mod clar, nu dorim să adăugăm înregistrări la tabelul antet comandă decât dacă am adăugat cu succes primul client nou. Aceasta este situația clasică în care am folosi o tranzacție. Cu toate acestea, nu am dori să adăugăm detaliile comenzii dacă antetul comenzii nu poate fi salvat. Și aceasta implică o tranzacție, dar ar trebui să respingem atât clientul, cât și antetul comenzii doar pentru că nu putem actualiza o linie de detalii? În unele situații, răspunsul poate fi da, dar în cele mai multe cazuri ne-am dori cu adevărat ca adăugarea clientului să „lipească” chiar dacă comanda nu ar putea fi adăugată. O singură tranzacție nu este suficientă, dar o pereche de tranzacții imbricate va face față foarte bine factura, așa cum este ilustrat mai jos:

*** Începeți tranzacția cea mai exterioară („Wrapper”)

ÎNCEPE TRANZACȚIA

*** Actualizați mai întâi tabelul Clienți

llTxl = TableUpdate( 1, .F., „client” )

IF llTxl

*** Tabelul clienților a fost actualizat cu succes

*** Începe a doua tranzacție „internă” pentru Comenzi

ÎNCEPE TRANZACȚIA

llTx2 = TableUpdate( 1, .F., „header comandă”)

IF llTx2

*** Comenzi actualizate, acum încercați detalii

llTx2 = TableUpdate( 2, .F., „detalii comandă”)

IF llTx2

*** Ambele tabele de comenzi au fost actualizate cu succes

*** Deci, comite tranzacția de comenzi

ÎNCHEIAȚI TRANZACȚIA

ALTE

*** Actualizarea detaliilor comenzii nu a reușit

*** Derulați înapoi întreaga tranzacție de comenzi

ROLLBACK

ENDIF

ALTE

*** Actualizarea antetului comenzii nu a reușit - nu are rost să încerci detalii

ROLLBACK

ENDIF

*** Dar actualizarea clientului a reușit deja, așa că angajați-vă

ÎNCHEIAȚI TRANZACȚIA

ALTE

*** Actualizarea clientului a eșuat - nu are rost să continuați

ROLLBACK

ENDIF

Acest cod poate părea puțin ciudat la prima vedere, dar subliniază faptul că BEGIN..END TRANSACTION nu constituie o structură de control. Observați că există două comenzi de pornire, una pentru fiecare tranzacție și două comenzi „Commit”, una pentru tabelul clienți și una pentru perechea de tabele de comenzi. Cu toate acestea, există trei comenzi de derulare înapoi. Unul pentru tranzacția exterioară, dar două pentru tranzacția internă, pentru a răspunde faptului că oricare dintre tabelele implicate ar putea eșua.

Logica devine puțin mai complicată pe măsură ce sunt implicate mai multe mese, dar principiile rămân aceleași. Cu toate acestea, atunci când sunt implicate multe tabele sau dacă scrieți rutine generice pentru a gestiona un număr nedeterminat de tabele la fiecare nivel, va fi probabil necesar să împărțiți tranzacțiile în metode separate pentru a gestiona funcțiile Update, Commit și Rollback și pentru a utiliza funcția TXNLEVEL() pentru a ține evidența numărului de tranzacții. (Rețineți că Visual FoxPro este limitat la cinci tranzacții simultane.)
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Câteva lucruri de urmărit atunci când utilizați tamponarea în aplicații

Nu se poate folosi OLDVAL() pentru a reveni la un câmp din tamponarea tabelului

Poate v-ați întrebat, când citiți discuția despre soluționarea conflictelor de mai devreme în acest capitol, de ce nu am folosit funcția OLDVAL() pentru a anula modificările unui utilizator în același mod în care am folosit valoarea returnată de CURVAL() pentru a șterge conflicte în diferite domenii. Răspunsul este pur și simplu că nu putem face acest lucru atunci când folosim orice formă de buffering de tabel dacă câmpul este folosit fie într-un index primar, fie într-un index candidat fără a obține o eroare „Unicitatea indexului <numele> este încălcat”. Acesta este o eroare recunoscută în toate versiunile de Visual FoxPro și, deoarece soluția oferită de Microsoft este utilizarea funcției TableRevert() în schimb, ni se pare puțin probabil ca aceasta să fie remediată vreodată.

Cu toate acestea, aceasta nu pare a fi o soluție complet satisfăcătoare, deoarece TableRevert() nu poate funcționa la altceva decât la nivelul „Rând” și, prin urmare, anularea unei modificări a unui câmp cheie fără a pierde orice alte modificări din aceeași înregistrare necesită puțin mai multă gândire. Cea mai bună soluție pe care am găsit-o este să folosim comanda SCATTER NAME pentru a crea un obiect ale cărui proprietăți sunt denumite la fel ca și câmpurile din tabel. Valorile atribuite proprietăților obiectului sunt valorile curente din memoria tampon de înregistrare și putem modifica valorile proprietăților folosind o atribuire simplă. Următorul program ilustrează atât problema, cât și soluția:

**************************************************** ********************

* 	Program. ShoOVal.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: ilustrează problema cu utilizarea OldVal() pentru a reveni la câmp

* 	..........:care este folosit într-o cheie Candidat

* 	..........:Ref: MS Knowledgebase PSS ID Number: Q157405

**************************************************** ********************

*** Creați și completați un exemplu de tabel

CREA

Eșantion TABLE ( Fieldl

C(5) UNIC, Câmp2 N(2) )

INTRODUCE

ÎN

probă

Câmpul 1

Câmpul 2

VALORI

unu

INTRODUCE

ÎN

probă

Câmpul 1

Câmpul 2

VALORI

Două

INTRODUCE

ÎN

probă

Câmpul 1

Câmpul 2

VALORI

Trei

(

(

(

)

)

)

(

(

(

1)

2)

3)

*** Forțați în modul Table Buffered

ACTIVATĂ MULTILOCK

CURSORSETPROP( „Buffering”, 5 )

*** ÎNTÂI PROBLEMA

*** Schimbați câmpul cheie

MERGI SUS

ÎNLOCUIȚI câmpul CU „patru”, câmpul 2 CU 4

OCOLIRE

SKIP -1

*** Reveniți valoarea utilizând OldVal()

ÎNLOCUIȚI câmpul CU OLDVAL(„Fieldl”)

OCOLIRE

SKIP -1

*** Acum primiți un mesaj de eroare „Unicitatea indexului FIELD1 este încălcat”.

*** Faceți clic pe IGNORE și întoarceți tabelul - pierde modificările în toate câmpurile! TableRevert(.T.)

*** ACUM SOLUȚIA

*** Repetați înlocuirea

MERGI SUS

ÎNLOCUȚIȚI câmpul 1 CU „patru”, câmpul 2 CU 4

OCOLIRE

SKIP -1

*** Împrăștiați câmpurile într-un obiect

NUME SCATTER loReverter

*** Reveniți valoarea câmpului cheie

loReverter.Field1 = OLDVAL('Field1' )

*** Întoarceți rândul din tabel

TableRevert(.F.)

*** Aduna valori înapoi

GATHER NAME loReverter

OCOLIRE

SKIP-1

*** NOTĂ: Nicio eroare, iar modificarea din Câmp2 este păstrată

*** Confirmați revenirea

TabelUpdate(1)

BROW ACUM Așteaptă

La momentul scrierii, comportamentul descris mai sus era destul de neregulat atunci când un șir de caractere a fost folosit ca cheie candidată. De exemplu, dacă ÎNLOCUȚI câmpul CU „Șapte” nu primiți deloc o eroare! Cu toate acestea, nu este nimic magic la șirul „șapte”, deoarece s-au găsit câteva alte valori care nu au cauzat o eroare, dar nu am putut discerne un model în, sau formula vreo explicație logică pentru, comportamentul observat.

Am inteles! Buffering de rând și comenzi care mută indicatorul de înregistrare

Am observat mai devreme că modificările aduse unei înregistrări într-un tabel cu buffer de rând sunt efectuate automat de Visual FoxPro ori de câte ori indicatorul de înregistrare pentru acel tabel este mutat. Acest lucru este implicit în proiectarea Row Buffering și este în întregime de dorit. Ceea ce nu este atât de de dorit este că nu este întotdeauna evident că o anumită comandă va muta de fapt indicatorul de înregistrare și acest lucru poate duce la rezultate neașteptate. De exemplu, este previzibil că lansarea unei comenzi de căutare sau de ignorare va muta înregistrarea

pointer și, prin urmare, nu am permite în mod normal să fie executată o astfel de comandă fără a verifica mai întâi modul buffer și, dacă buffering-ul rândurilor este în vigoare, a verifica dacă există modificări necomite.

În mod similar, v-ați aștepta ca utilizarea unei comenzi goto să mute și indicatorul de înregistrare dacă înregistrarea specificată nu a fost deja selectată. Cu toate acestea, goto mută întotdeauna indicatorul de înregistrare, chiar dacă utilizați forma GOTO RECNO() a comenzii (care păstrează indicatorul de înregistrare pe aceeași înregistrare) și astfel va încerca întotdeauna să comite modificările în așteptare în tamponarea rândurilor.

De fapt, orice comandă care poate lua fie un număr de înregistrare explicit, fie are o clauză Scope ( FOR sau WHILE) va determina mutarea indicatorului de înregistrare și este, prin urmare, o cauză probabilă a problemelor atunci când este utilizată împreună cu Row Buffering. Există multe astfel de comenzi în Visual FoxPro, inclusiv cele evidente precum SUM, AVERAGE și calcul, precum și unele mai puțin evidente, cum ar fi COPY TO ARRAY și UNLOCK.

Acest ultim este deosebit de furtun. Ceea ce înseamnă este că, dacă utilizați blocarea explicită cu un tabel cu buffer de rând, atunci deblocarea unei înregistrări este direct echivalent cu emiterea unui TableUpdate() și pierdeți imediat capacitatea de a anula modificările. Nu suntem siguri dacă acesta a fost într-adevăr comportamentul intenționat (deși putem ghici!), dar subliniază punctele menționate mai devreme în capitol. În primul rând, nu există un loc real pentru tamponarea rândurilor într-o aplicație și, în al doilea rând, cel mai bun mod de a gestiona blocarea atunci când utilizați tamponarea este să permiteți Visual FoxPro să o facă.
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Capitolul 9 - Vizualizări în special, SQL în general

„Există multe poteci către vârful muntelui, dar priveliștea este întotdeauna aceeași.” (Proverb chinezesc)

Cele două capitole anterioare s-au concentrat în principal pe gestionarea și utilizarea tabelelor în Visual FoxPro, dar există multe, mult mai multe care pot fi făcute prin ramificarea în lumea SQL în general și în Views în special. Deoarece ne concentrăm pe Visual FoxPro, acest capitol tratează în principal vizualizările locale și nu abordează subiectul vizualizărilor offline sau de la distanță în detaliu. Sperăm că veți găsi în continuare suficiente pepite aici pentru a vă menține interesat.
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Vizualizări Visual FoxPro

Exemplul de cod pentru acest capitol include o bază de date separată (CH09.DBC) care conține tabelele și vederile locale utilizate în exemplele pentru această secțiune. Nu am inclus exemple specifice care utilizează vizualizări la distanță (fie doar pentru că nu putem garanta că veți avea o sursă de date adecvată configurată pe mașina dvs.), dar, acolo unde este cazul, am indicat orice diferențe semnificative între vizualizările locale și la distanță.
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Ce este mai exact o vedere?

Fișierul de ajutor Visual FoxPro definește o vizualizare în următorii termeni:

„O definiție personalizată de tabel virtual care poate fi locală, la distanță sau parametrizată. Vizualizările fac referire la unul sau mai multe tabele sau alte vederi. Acestea pot fi actualizate și pot face referire la tabele la distanță.”

Cuvântul cheie aici este „definiție”, deoarece o vizualizare este de fapt o interogare SQL care este stocată într-un container al bazei de date, dar, spre deosebire de un simplu fișier Query (.QPR), o vizualizare este reprezentată vizual în containerul bazei de date ca și cum ar fi de fapt un masa. În toate scopurile practice, poate fi tratat ca și cum ar fi într-adevăr un tabel (adică pentru a deschide o vizualizare, pur și simplu o utilizați și poate fi, de asemenea, adăugat la mediul de date al unui formular în momentul proiectării). Există cel puțin trei beneficii majore care pot fi obținute din utilizarea vizualizărilor.

În primul rând, deoarece o vizualizare nu stochează de fapt date în mod persistent, nu necesită spațiu de stocare permanent pe disc. Cu toate acestea, deoarece definiția este stocată, vizualizarea poate fi re-creată oricând este necesar, fără a fi nevoie să redefiniți SQL-ul. În al doilea rând, spre deosebire de un cursor creat direct de o interogare SQL, o vizualizare este întotdeauna actualizabilă și, dacă este necesar, poate fi definită și pentru a actualiza tabelul sau tabelele pe care se bazează. În al treilea rând, o vizualizare se poate baza pe tabele locale (VFP) sau poate folosi tabele dintr-o sursă de date la distanță (folosind ODBC și o „Conexiune”) și poate folosi chiar și alte vederi ca sursă pentru datele sale - sau orice combinație a de mai sus.
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Cum creez o vizualizare?

Visual FoxPro permite crearea unei vizualizări în două moduri, fie vizual (folosind View Designer) fie programatic cu comanda CREATE SQL VIEW. Pentru detalii complete despre utilizarea View Designer, vezi Capitolul 8: Crearea vizualizărilor din Ghidul Programerà. (Totuși, rețineți că, la fel ca toți designerii, View Designer are unele limitări și anumite tipuri de vederi chiar trebuie create în cod.) Indiferent de metoda pe care o utilizați, procesul implică patru pași:

• 	Definiţi câmpurile pe care le va conţine vizualizarea şi tabelul (tabelele) din care vor fi selectate acele câmpuri

• 	Specificați orice condiții de unire, filtre sau parametri necesari

• 	Definiți mecanismul și criteriile de actualizare (dacă vizualizarea urmează să fie utilizată pentru a-și actualiza tabelele sursă)

• 	Denumiți și salvați vizualizarea într-un container de bază de date

Un mare avantaj al utilizării designerului de vizualizare pentru a crea vederi este că ascunde complexitatea codului necesar și, deși codul nu este de fapt dificil, poate exista o mulțime de el (chiar și pentru o vizualizare simplă), ca exemplul următor spectacole. Iată SQL-ul pentru o vizualizare simplă, dar actualizabilă, într-un singur tabel, care listează numele companiilor după oraș pentru o anumită țară, așa cum se arată în View Designer:

SELECT DISTINCT Clients.clisid, Clients.climpy, Clients.clicity;

DE LA ch09!clienți;

UNDE Clients.clictry = ?cCountry;

COMANDĂ DE Clients.clicity, Clients.climpy

În timp ce aici este codul necesar pentru a crea aceeași vizualizare în mod programatic:

CREATE SQL VIEW "CPYBYCITY" ;

AS SELECT DISTINCT Clients.clisid, Clients.climpy, Clients.clicity ;

DE LA ch09!clienti ;

UNDE Clients.clictry = ?cCountry ;

COMANDĂ DE Clients.clicity, Clients.climpy

DBSetProp('CPYBYCITY', 	'Vizualizare','UpdateType', 1)
DBSetProp('CPYBYCITY', 	'Vizualizare','WhereType', 3)
DBSetProp('CPYBYCITY', 	'Vizualizare','FetchMemo', .T.)
DBSetProp('CPYBYCITY', 	'Vizualizare','Trimite actualizări', .T.)
DBSetProp('CPYBYCITY', 	'Vizualizare','UseMemoSize', 255)
DBSetProp('CPYBYCITY', 	'Vizualizare','FetchSize', 100)
DBSetProp('CPYBYCITY', 	'Vizualizare','MaxRecords', -1)
DBSetProp('CPYBYCITY', 	'Vizualizare','Tabele', 'ch0 9 !clienti')
DBSetProp('CPYBYCITY', 	'Vizualizare','Pregătit', .F.)
DBSetProp('CPYBYCITY', 	'Vizualizare','CompareMemo', .T.)
DBSetProp('CPYBYCITY', 	'Vizualizare','FetchAsNeeded', .F.)
DBSetProp('CPYBYCITY', 	'Vizualizare','FetchSize', 100)
DBSetProp('CPYBYCITY', 	'View','ParameterList', "cCountry,'C'"

DBSetProp('CPYBYCITY', 'Vizualizare', 'Conment', "")

DBSetProp('CPYBYCITY', 'Vizualizare', 'BatchUpdateCount', 1)

DBSetProp('CPYBYCITY', 'View', 'ShareConnection', .F.)

DBSetProp('CPYBYCITY.clisid', 'Field', 'KeyField', .T.)

DBSetProp('CPYBYCITY.clisid', 'Field', 'Updatable', .F.)

DBSetProp('CPYBYCITY.clisid', 'Field', 'UpdateName', 'ch09!clients.clisid')

DBSetProp('CPYBYCITY.clisid', 'Field', 'DataType', "I")

DBSetProp('CPYBYCITY.climpy',

DBSetProp('CPYBYCITY.climpy',

„Field”, „KeyField”, .F.)

„Câmp”, „Actualizat”, .T.)

DBSetProp('CPYBYCITY.climpy', 'Câmp',

„UpdateName”, „ch09!clients.climpy”)

DBSetProp('CPYBYCITY.climpy', 'Câmp',

„DataType”

„C(40)”)

DBSetProp('CPYBYCITY.clicity', 'Field', 'KeyField', .F.)

DBSetProp('CPYBYCITY.clicity', 'Field',

„Actualizat”, .T.)

DBSetProp('CPYBYCITY.clicity', 'Field',

„UpdateName”, „ch09!clients.clicity”)

DBSetProp('CPYBYCITY.clicity', 'Field',

„DataType”

„C(15)”)

În primul rând, trebuie spus că nu este chiar atât de rău pe cât pare! Multe dintre setările nivelului de vizualizare definite aici sunt valorile implicite și trebuie specificate doar atunci când aveți nevoie de ceva configurat diferit. Acestea fiind spuse, rămâne totuși un exercițiu non-trivial (doar ca toate afirmațiile să fie tastate corect este destul de dificil!). Deci, cum putem simplifica un pic lucrurile? Ei bine, Visual FoxPro include un mic instrument foarte util numit GENDBC.PRG care creează un program pentru a re-genera un container de bază de date (il veți găsi în subdirectorul ..\VFP60\TOOLS\GENDBC\). Vizualizările sunt, așa cum sa menționat mai sus, stocate într-un container de bază de date. Deci, de ce să nu lăsăm Visual FoxPro să facă toată munca grea?

Pur și simplu creați un container de baze de date temporar (gol) și definiți-vă vizualizarea în el. Rulați GENDBC și aveți un fișier de program care nu numai că vă documentează vizualizarea, dar poate fi rulat pentru a recrea vizualizarea în containerul de bază de date real. Mai important, există, după cum am spus, unele limitări la ceea ce se poate ocupa de proiectant. O astfel de limitare implică crearea de vederi care unesc mai multe tabele legate de un părinte comun, dar nu unul cu celălalt. Clauzele de unire produse de designer nu pot face față cu adevărat acestei situații și singura modalitate de a asigura rezultatele corecte este crearea unor astfel de vederi în cod. Utilizarea designerului pentru a face cea mai mare parte a lucrării și simpla editare a condițiilor de îmbinare într-un fișier PRG este cea mai simplă modalitate de a crea vederi complexe.

Un cuvânt de precauție! Dacă creați vizualizări în mod programatic, asigurați-vă că nu încercați din neatenție să le modificați în designerul de vizualizare, deoarece s-ar putea să ajungeți la o vizualizare care nu mai face ceea ce trebuie. Vă recomandăm insistent denumirea diferită a acestor vederi pentru a le distinge de vederile care pot fi modificate în siguranță în designer. Pentru a modifica o vizualizare creată prin programare, pur și simplu editați programul care o creează și rulați din nou.

Copyright 2000 de către Marcia Akins, Andy Kramek și Rick Schummer Toate drepturile rezervate

Când ar trebui să folosesc o vizualizare în loc de un tabel?

De fapt, nu trebuie să mai folosești niciodată o masă! Puteți utiliza întotdeauna o vizualizare, chiar dacă acea vizualizare este pur și simplu o copie exactă a unui singur tabel. Vom acoperi acest punct mai târziu în capitol (vezi secțiunea Scalabilitate). Cu toate acestea, există cu siguranță unele ocazii în care credem că o vizualizare ar trebui folosită mai degrabă decât utilizarea directă a tabelelor.

Prima, și probabil cea mai evidentă, este atunci când se creează rapoarte care necesită date din tabelele aferente. În timp ce Visual FoxPro Report Writer este un instrument destul de flexibil, nu este (în opinia noastră) ușor de utilizat atunci când încercați să lucrați cu mai multe tabele. O singură vizualizare poate reduce o structură relațională complexă la un „fișier plat”, care este ușor de gestionat de către redactorul raportului, ușurând mult sarcina de a crea rapoarte care utilizează date grupate.

O altă utilizare, poate mai puțin evidentă, este aceea că unele comenzi, cum ar fi grilele și casetele de listă sau combinate, adesea trebuie să folosească tabele de căutare pentru a afișa descrierile asociate câmpurilor de cod. Crearea unei vizualizări actualizabile pentru a combina descrierile împreună cu datele „reale” oferă o modalitate simplă și eficientă de a gestiona astfel de sarcini. Capitolul 6 (Grile: comenzile neînțelese) include un exemplu care utilizează o vizualizare tocmai în acest scop - o vizualizare, folosită ca sursă de înregistrare pentru grilă, include un câmp de descriere dintr-un tabel de căutare și toate câmpurile, cu excepția descrierii, sunt actualizabile.

Vizualizările oferă, de asemenea, un mecanism pentru accesarea datelor în versiunile mai vechi ale FoxPro, fără a fi nevoie să convertiți datele sursă. Dacă încercați să adăugați un tabel FoxPro 2.x la un container al bazei de date Visual FoxPro, tabelele devin inutilizabile de către aplicația 2.x. În cazurile în care trebuie să accesați același tabel atât în FoxPro 2.x, cât și în Visual FoxPro, o vizualizare oferă soluția. Deși vizualizarea trebuie să fie stocată într-un DBC, tabelele pe care le utilizează nu trebuie să fie.

Această capacitate, desigur, nu se limitează la tabelele FoxPro. O vizualizare poate fi definită pentru a prelua date din orice sursă de date în Visual FoxPro, cu condiția să se stabilească o conexiune ODBC la acea sursă de date. Odată ce datele au fost introduse într-o vizualizare, acestea pot fi manipulate exact în același mod ca și cum ar fi date native Visual FoxPro. Făcând o astfel de vizualizare „la distanță” actualizabilă, orice modificări făcute în Visual FoxPro pot fi trimise la sursa de date inițială.

Ultima ocazie de a utiliza o vizualizare este atunci când trebuie să obțineți un subset de date. În această situație, crearea unei vizualizări parametrizate este adesea mai bună decât simpla setare a unui filtru. De fapt, atunci când aveți de-a face cu grile, este întotdeauna mai bine, deoarece grilele nu pot folosi Rushmore pentru a optimiza filtrele. Pentru mai multe detalii despre utilizarea vizualizărilor în grile, consultați Capitolul 6.
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Rezistă! Ce este o vizualizare parametrizată?

Ah! Nu am menționat asta? O vizualizare nu trebuie să includă întotdeauna toate datele dintr-un tabel și nici nu trebuie să specificați întotdeauna condiția exactă a fdter la momentul proiectării. În schimb, puteți defini o vizualizare care include o condiție de filtru care se va baza pe un parametru furnizat în timpul execuției - de aici termenul „Vizualizare parametrizată”.

O vizualizare parametrizată este definită prin includerea unei condiții de filtru care se referă la un nume de variabilă, proprietate sau câmp într-un tabel deschis care a fost prefixat cu un „?” după cum urmează:

WHERE Clients.clicity = ?city_to_view ;

Când vizualizarea este deschisă sau interogată din nou, Visual FoxPro va căuta variabila numită și, dacă găsește, va aplica pur și simplu condiția specificată în instrucțiunea SQL care populează vizualizarea. O vizualizare parametrizată simplă este inclusă în mostrele pentru acest capitol (vezi Iv CpyByCity în CH09.dbc). Dacă parametrul numit nu este găsit atunci când vizualizarea este deschisă sau re-interogat, este afișată o casetă de dialog care solicită o valoare pentru parametru - astfel:

Figura 9.1 Dialog de vizualizare a parametrilor

Definirea parametrilor de vizualizare

Observați că promptul începe „Introduceți o valoare a caracterului...”. De unde știe Visual FoxPro că City To View este un șir de caractere? Răspunsul este că nu! Această vizualizare specială a fost creată în designerul de vizualizare și, atunci când utilizați designerul, există o opțiune în panoul „Interogare” din meniul de sistem ÇViewparameters”) care vă permite să definiți numele și tipurile de date ale oricăror parametri pe care îi specificați în definiție pentru vedere.

Figura 9.2 Vizualizați definiția parametrului

Dacă intenționați să utilizați dialogul pentru parametrii de vizualizare într-o aplicație și definiți acele vederi în designer, definiți întotdeauna parametrii în mod explicit în acest dialog. (V-am sugera să utilizați și nume foarte descriptive!) Dacă nu definiți parametrul, atunci dialogul afișat utilizatorului nu va include tipul de valoare așteptat și va indica pur și simplu „Introduceți o valoare pentru City To View”. (Pentru a face același lucru atunci când definiți o vizualizare în cod, necesită doar (încă un alt) calí la funcția DBSETPROPQ).

Cu toate acestea, în opinia noastră, simpla folosire a dialogului implicit nu este un lucru bun de făcut într-o aplicație din trei motive. În primul rând, Visual FoxPro nu validează intrarea pe care utilizatorul o introduce în dialog (chiar și atunci când predefiniti parametrul și tipul său de date) și nici nu puteți valida acea intrare înainte de a fi aplicată. Deci, dacă parametrul este invalid, veți primi pur și simplu o eroare. În al doilea rând, dialogul în sine nu este foarte ușor de utilizat. La urma urmei, ce va face utilizatorul obișnuit despre ceva care cere un „Parametru de vizualizare”? În cele din urmă, dacă utilizați mai mulți parametri atunci, deoarece Visual FoxPro poate accepta doar un parametru la un moment dat, utilizatorului i se va prezenta o serie de dialoguri una după alta (foarte urâte).

Utilizarea vizualizărilor parametrizate într-un formular

Soluția este într-adevăr foarte simplă - trebuie doar să vă asigurați că parametrul corespunzător a fost definit, este în domeniu și a fost populat înainte de a deschide sau a re-interoga vizualizarea. Există multe moduri de a face acest lucru, dar metoda noastră preferată este de a crea proprietăți pentru parametrii de vizualizare la nivel de formular și apoi de a transfera valorile din acele proprietăți în variabilele adecvate, indiferent de metoda care interogează vizualizarea. Acest lucru are două beneficii. În primul rând, se asigură că valorile curente utilizate de vizualizare sunt disponibile pentru întregul formular. În al doilea rând, ne permite să validăm parametrii înainte ca aceștia să fie transferați în vizualizare.

Pentru a permite unui utilizator să specifice parametrii necesari, trebuie să oferim utilizatorului un mijloc adecvat pentru introducerea parametrilor. Acesta poate fi un formular pop-up sau un fel de control de selecție pe formularul în sine. Cel mai important, putem obține, de asemenea, mai mulți parametri într-o singură operație, dacă este necesar. Un formular care oferă un exemplu de astfel de mecanism este inclus în exemplul de cod pentru acest capitol (VuParams.scx).

Setarea Vizualizare Pdidinelers



Nume client |În jurul Cornului

		ReQueryExil
101 ianuarie 1999			

Data de începere a campaniei

	KeyCompanyCampaignStartFinishRunsActive
	99Bonus în jurul HornMillennium 0012/12/199901/31/200050T
	99În jurul cornului Căderea înapoi 9909/06/199911/20/199975T
		Around the HornSummer Madness 9S05/10/199908/08/199990F
	99Around the HornGo 200001/06/199904/06/199990T
	99În jurul HornSpring Înainte 9901/04/199904/14/1999100F
							
							
							
							
							

Figura 9.3 Utilizarea unei vizualizări parametrizate într-un formular

Acest formular folosește o vizualizare (lv_adcampanes) care unește trei tabele, care sunt legate așa cum se arată în figura

9.4 și acceptă doi parametri, unul pentru „Numele clientului” și celălalt pentru „Data de începere”.

Figura 9.4 Tabele pentru View lv_AdCampanes

Vizualizarea a fost adăugată la mediul de date al formularului cu proprietatea nodataonload setată la .T. Deoarece tabelul „Clienți” este folosit atât în vizualizare, cât și ca sursă de rând pentru caseta combinată, proprietatea BufferModeoverride are setată la niciunul pentru a dezactiva tamponarea pe acel tabel (chiar dacă, în acest exemplu, vizualizarea nu este actualizabilă) . Formularul are două proprietăți personalizate pentru a stoca rezultatele selecțiilor utilizatorului. Butonul „ReQuery” are cod în metoda sa Click pentru a se asigura că aceste proprietăți conțin valori și pentru a le transfera la parametrii definiți pentru vizualizare înainte de a apela funcția requeryo.

Copyright 2000 de către Marcia Akins, Andy Kramek și Rick Schummer Toate drepturile rezervate

Cum controlez conținutul unei vizualizări când este deschisă?

Comportamentul implicit al oricărei vizualizări (locale sau la distanță) este că ori de câte ori vizualizarea este deschisă pentru prima dată, aceasta se populează prin executarea SQL-ului care o definește. Acest lucru se aplică dacă deschideți vizualizarea în mod explicit cu o comandă de utilizare în cod (sau din fereastra de comandă) sau implicit prin adăugarea acesteia în mediul de date al unui formular. Cu toate acestea, acesta poate să nu fie întotdeauna comportamentul pe care îl doriți, mai ales când aveți de-a face cu vederi parametrizate sau cu orice vizualizare, locală sau la distanță, care accesează tabele mari.

Pentru a împiedica o vizualizare să încarce toate datele sale, trebuie să specificați opțiunea nodata când o deschideți. În cod, cuvântul cheie este adăugat la sfârșitul comenzii de utilizare normală, astfel:

UTILIZAȚI lv_CpyByCity NODATA

Cu toate acestea, în mediul de date al unui formular, cursorul pentru vizualizare are o proprietate NoDataOnLoad care este setată, implicit, la .f. Setarea acestei proprietăți la .t. se asigură că nu primiți dialogul „Introduceți valoarea pentru xxx” atunci când inițializați formularul.

Indiferent de modul în care vă deschideți vizualizarea, rezultatul este același: obțineți o vizualizare constând din toate câmpurile definite, dar fără înregistrări. Într-o formă, acest lucru permite ca controalele legate să fie inițializate corect chiar și atunci când nu există date reale de afișat. Cu toate acestea, cu excepția cazului în care ulterior (de obicei, în metoda Init sau o metodă numită din Init) populați vizualizarea, orice controale asociate acesteia vor fi dezactivate atunci când formularul este afișat. Visual FoxPro oferă două funcții care operează pe vizualizări pentru a controla modul în care își obțin datele, REQUERY() și REFRESH() .

Care este diferența dintre REQUERY() și REFRESH()

Funcția REQUERY() este utilizată pentru a popula o vizualizare care a fost deschisă fără date. De asemenea, este folosit pentru a actualiza conținutul unei vizualizări parametrizate ori de câte ori parametrul s-a modificat. Când o vizualizare este solicitată, SQL-ul care definește vizualizarea este executat și setul de date corespunzător este preluat. Funcția returnează fie 1 (indicând că interogarea a reușit), fie 0 (dacă interogarea a eșuat). Cu toate acestea, rețineți că valoarea returnată NU vă spune dacă au fost preluate înregistrări, doar dacă SQL-ul a fost executat corect. Pentru a obține numărul de înregistrări care se potrivesc, mai trebuie să utilizați _tally, așa cum arată următorul cod:

UTILIZAȚI lv_cpybycity NODATA

City_to_view = „Londra”

? REQUERY() && returnează 1

TALLY && Returnări 6

City_to_view = „Peterborough”

? REQUERY() && returnează 1

? _TALLY && returnează 0

Funcția refresh() are un scop complet diferit. Actualizează conținutul unei vizualizări existente pentru a reflecta orice modificări ale datelor de bază de la ultima solicitare a vizualizării. În mod implicit, numai înregistrarea curentă este reîmprospătată, deși funcția vă permite să specificați numărul de înregistrări și intervalul pentru acele înregistrări (pe baza unui decalaj față de înregistrarea curentă) care vor fi actualizate. Cu toate acestea, REFRESH() nu interogează din nou datele, chiar și într-o vizualizare parametrizată pentru care parametrul s-a schimbat, așa cum este ilustrat aici:

UTILIZAȚI lv_cpybycity NODATA

City_to_view = „Londra”

? REQUERY() && returnează 1

? _TALLY && Retururi 6

? clicity && Returns „Londra”

City_to_view = „Peterborough”

? REFRESH() && Returnează 1

? clicity && Returns „Londra”

Dacă refresh () pur și simplu ignoră parametrul modificat, la ce folosește acesta? Răspunsul este că, deoarece o vizualizare este întotdeauna creată local pe computerul client și este exclusivă pentru utilizatorul curent, pot fi făcute modificări ale tabelului de bază care nu sunt reflectate în vizualizare. Acest lucru este ușor de văzut dacă deschideți o vizualizare și apoi mergeți la tabelul de bază și faceți o modificare direct. Vizualizarea în sine nu se va schimba, dar dacă apoi încercați să modificați vizualizarea și să o salvați, veți primi un conflict de actualizare. Și mai rău, anularea modificării în vizualizare nu vă va oferi valoarea curentă din tabel - doar cea care a fost inițial în vizualizare. Singura modalitate de a actualiza vizualizarea este să apelați un

REÎMPROSPĂTA().

Acest lucru se datorează faptului că vizualizarea are propriul buffer, independent de cel pentru tabelul de bază. Nu este cu adevărat o problemă dacă interogați din nou o vizualizare de fiecare dată când utilizatorul dorește să acceseze un nou set de date. Un requeryo populează întotdeauna vizualizarea din nou. Cu toate acestea, dacă aveți o situație în care mai multe înregistrări sunt preluate într-o vizualizare și un utilizator poate face modificări la oricare dintre ele, cel mai bine este să vă asigurați că, pe măsură ce fiecare înregistrare este selectată, vizualizarea este reîmprospătată. Acest lucru asigură că ceea ce vede de fapt utilizatorul reflectă starea curentă a tabelului de bază.
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De ce modificările făcute într-o vizualizare nu intră uneori în tabelul de bază?

Acest lucru se poate întâmpla atunci când lucrați cu o vizualizare locală actualizabilă, care se bazează pe un tabel care era deja deschis și stocat în tampon atunci când vizualizarea a fost deschisă. Problema apare pentru că atunci aveți două „straturi” de buffering în vigoare, dar vizualizarea știe doar despre unul dintre ele. Comportamentul standard al Visual FoxPro atunci când lucrați cu o vizualizare locală este de a deschide tabelul de bază fără tamponare atunci când vizualizarea este prima interogată. Pentru Visual FoxPro nu contează dacă vizualizarea este deschisă din linia de comandă, într-un program sau prin mediul de date al unui formular.

Acest comportament asigură că atunci când un TableUpdate() este apelat pentru vizualizare (care folosește întotdeauna tamponare optimistă), modificările aduse tabelului de bază sunt imediat comise. Cu toate acestea, dacă tabelul este în sine în buffer, tot ceea ce este actualizat este tamponul tabelului și este necesar un alt TableUpdate() pentru a se asigura că modificările sunt salvate. Pentru a evita această problemă, nu deschideți în mod explicit tabelul (sau tabelele) pe care se bazează vizualizarea. Cu alte cuvinte, atunci când utilizați o vizualizare într-un formular, nu adăugați tabelele sursă pentru vizualizare în mediul de date al formularului. (Dacă trebuie neapărat să faceți acest lucru, atunci setați proprietatea buffermodeoverride pentru aceste tabele pentru a vă asigura că sunt deschise fără tamponare.)

Există, desigur, o altă situație în care poate apărea problema. Acesta este momentul în care utilizați sesiunea de date implicită și aveți mai multe formulare deschise. Evident, deoarece diferitele forme pot folosi tabelele în moduri diferite, nu există o modalitate sigură de a ști că tabelele utilizate de o vizualizare într-o formă nu au fost deja deschise într-o altă formă fără a testa în mod explicit fiecare tabel. Dacă o masă a fost deschisă și tamponată printr-o altă formă, ce poți face în privința asta? Nu puteți schimba pur și simplu modul tampon al tabelului. (Aceasta ar afecta și cealaltă formă.) Ați putea modifica comenzile de actualizare pentru a forța un TableUpdate() explicit pe tabelul de bază, dar asta pare (oricum nouă) să învingă unul dintre principalele beneficii ale utilizării unei vizualizări - care este că vă permite să utilizați date din mai multe tabele și să le tratați ca și cum ar fi într-adevăr doar un singur tabel implicat.

Soluția la această dilemă este să vă asigurați că utilizați Private DataSessions pentru formularele care folosesc vizualizări actualizabile. Folosind o sesiune de date privată, forțați efectiv Visual FoxPro să deschidă din nou tabelele subiacente (analog cu a face o utilizare... din nou pe tabel) și atunci nu poate exista nicio ambiguitate cu privire la starea tamponării. De fapt, am merge mai departe și am spune că, ca regulă generală, nu ar trebui să amestecați vederile actualizabile și tabelele pe care se bazează în aceeași sesiune de date. Fie utilizați vizualizări pentru orice (rețineți că puteți crea o vizualizare care este pur și simplu o „copie” directă a tabelului) sau utilizați tabelele direct!
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De ce aș vrea să creez o vizualizare care este pur și simplu o copie a unui tabel existent?

Există trei motive pentru a face acest lucru. Primul, așa cum sa discutat în secțiunea precedentă, este de a evita necesitatea de a amesteca tabelele și vizualizările în aceeași formă. Al doilea este atunci când datele reale sunt conținute într-o versiune mai veche a FoxPro și sunt utilizate de o altă aplicație scrisă în acea versiune, ceea ce ar împiedica pur și simplu să actualizați tabelele la formatul Visual FoxPro. Al treilea, și în opinia noastră cel mai important, este atunci când creați o aplicație scalabilă.

Ce înțelegeți prin aplicație „scalabilă”?

O aplicație scalabilă este una care este scrisă pentru a permite ca sursa datelor să fie schimbată din tabelele Visual FoxPro într-o altă sursă de date - de obicei un server back-end precum SQL Server sau Oracle. Unul dintre cele mai mari avantaje ale utilizării vizualizărilor este că aceeași definiție de vizualizare poate fi utilizată pentru a accesa fie tabele locale (de exemplu Visual FoxPro), fie date de la distanță (adică back-end). Singura diferență practică între o vizualizare locală și una la distanță este că cea din urmă necesită definirea unei „conexiuni” pentru a permite interogarea sursei de date. În toate celelalte privințe, comportamentul unei vizualizări locale și a unei vizualizări de la distanță este identic, iar comenzile pentru a le manipula sunt aceleași.

Aceasta înseamnă că puteți construi, testa și rula o aplicație în întregime în Visual FoxPro. De asemenea, puteți, la o dată ulterioară, să redefiniți vizualizările de la „local” la „la distanță” și să vă rulați aplicația dintr-o sursă de date diferită, fără a modifica niciun cod. (Acest lucru presupune, desigur, că numele tabelelor și structurile lor sunt aceleași atât în Visual FoxPro, cât și în baza de date back-end.)

Suna bine! Cum să fac asta?

În principiu, este foarte simplu - folosiți vizualizări în loc de tabele. Cu toate acestea, nu este vorba doar de a înlocui vederile cu tabelele. Există multe probleme de luat în considerare deoarece, atunci când lucrați cu vizualizări, lucrați cu adevărat cu o sursă de date de la distanță. Prin urmare, o aplicație bazată pe vizualizare ar trebui să fie modelată pe o arhitectură client/server adecvată. Deci, după ce ați proiectat aplicația pentru a utiliza vizualizări care se bazează pe tabele locale Visual FoxPro, nu mai trebuie să utilizați tabele direct în aplicație. Acest lucru vă oferă o aplicație de lucru care poate fi schimbată ulterior pentru a utiliza o sursă de date diferită, fără a necesita nicio modificare a codului, deoarece odată ce o vizualizare a fost populată, pentru Visual FoxPro nu contează dacă se bazează pe date locale sau la distanță. Deci, cum ați converti de fapt o aplicație din vizualizări locale în vizualizări la distanță? Există două soluții posibile, presupunând că numele și structurile tabelelor sunt identice atât în Visual FoxPro, cât și în sursa de date de la distanță.

O modalitate este de a crea trei containere de baze de date. Primul conține tabelele locale Visual FoxPro, iar al doilea conține doar vizualizările locale bazate pe tabelele din primul. Al treilea conține vizualizările echivalente de la distanță (și informațiile relevante de conectare). Acest lucru vă permite să păstrați aceleași nume atât pentru vizualizările locale, cât și pentru cele de la distanță. În cadrul aplicației, furnizați un mecanism pentru a specifica care dintre containerele bazei de date bazate pe vizualizare va fi utilizat. (Acest lucru se poate face citind dintr-un fișier INI sau dintr-o setare de registry.) Prin simpla schimbare a acestui indicator al bazei de date, aplicația trece de la utilizarea vizualizărilor locale la la distanță și nu necesită niciun cod suplimentar.

Aceasta este cea mai flexibilă abordare, deoarece păstrează posibilitatea de a rula fie pe date locale, fie la distanță. De asemenea, necesită mai multă configurare și întreținere pentru a se asigura că vizualizările locale și la distanță sunt întotdeauna sincronizate cu tabelele. Ca și în toate, există un compromis aici.

A doua modalitate este de a converti vizualizările locale în vizualizări la distanță. Acest lucru se face cel mai bine prin crearea, ca și înainte, a mai multor containere de baze de date - deși în acest caz avem nevoie doar de două (unul pentru tabelele locale și unul pentru vizualizări). Pentru a converti vizualizările din local în remote, mai întâi generați codul pentru vizualizările locale (folosind GenDbc.prg) ca program. Acest program poate fi apoi modificat pentru a redefini vizualizările ca vizualizări la distanță. Programul modificat este apoi rulat pentru a genera un nou container de bază de date care include doar vizualizări la distanță.

Deși mai simplu de întreținut, aceasta este în esență o operațiune unidirecțională, deoarece pierdeți capacitatea de a rula împotriva datelor locale atunci când vizualizările sunt redefinite. Abordarea va depinde, ca întotdeauna, de nevoile specifice ale aplicației.

Conversia vizualizărilor locale în vizualizări la distanță în mod programatic

Următorul cod arată cât de puțin trebuie modificată definiția pentru o vizualizare locală pentru a o transforma într-o vizualizare la distanță. După cum puteți vedea, în afară de specificarea conexiunii și a numelui bazei de date, de fapt nu există nicio diferență:

LOCAL: CREATE SQL VIEW "CUSTOMERS" ;

AS SELECT * FROM Vfpdata!clienții

LA DISTANȚĂ: CREATE SQL VIEW "CLIENȚI" ;

CONECTARE LA DISTANȚĂ „SQL7”;

AS SELECT * FROM dbo.Clienți Clienți

De fapt, restul codului necesar pentru a crea vizualizarea locală sau la distanță este, din nou, cu excepția numelui bazei de date, identic - deci, de exemplu, definițiile Keyfield ("customerid") arată astfel:

LOCAL

* 	Recuzită pentru câmpul CLIENTI.customerid.

DBSetProp('CUSTOMERS.customerid', 'Field', 'KeyField', .T.)

DBSetProp('CUSTOMERS.customerid', 'Field', 'Updatable', .F.)

DBSetProp('CUSTOMERS.customerid', 'Field', 'UpdateName', 'vfpdata!customers.customerid')

DBSetProp('CUSTOMERS.customerid', 'Field', 'DataType', "C(5)")

LA DISTANTA

* 	Recuzită pentru câmpul CLIENTI.customerid.

DBSetProp('CUSTOMERS.customerid', 'Field', 'KeyField', .T.)

DBSetProp('CUSTOMERS.customerid', 'Field', 'Updatable', .F.)

DBSetProp('CUSTOMERS.customerid', 'Field', 'UpdateName', 'dbo.customers.customerid')

DBSetProp('CUSTOMERS.customerid', 'Field', 'DataType', "C(5)")

În timp ce codul pentru crearea conexiunii este, de asemenea, foarte simplu și arată astfel:

CREATE CONEXIUNE SQL7 ;

SURSA DE DATE „SQL7 Northwind” ;

UTILIZATOR „xxxxxx” ;

PAROLA „aaaaaa”

**** Proprietățile conexiunii

DBSetProp('SQL7', 'Conexiune', 'Asincron', .F.)

DBSetProp('SQL7', 'Conexiune', 'BatchMode', .T.)

DBSetProp('SQL7', 'Conexiune', 'Comentariu', '')

DBSetProp('SQL7', 'Conexiune', 'DispLogin', 1)

DBSetProp('SQL7', 	'Conexiune','ConnectTimeOut' , 15)
DBSetProp('SQL7', 	'Conexiune','DispWarnings',.F.)
DBSetProp('SQL7', 	'Conexiune','IdleTimeOut',0)
DBSetProp('SQL7', 	'Conexiune','QueryTimeOut',0)
DBSetProp('SQL7', 	'Conexiune','Tranzacţii',1)
DBSetProp('SQL7', 	'Conexiune','Bază de date', '' )	

Este puțin probabil ca într-un mediu de producție să lăsați toate aceste setări la valorile implicite (care este ceea ce vedem aici), dar cantitatea de modificare necesară este foarte limitată. Desigur, există o serie întreagă de probleme asociate cu proiectarea și construirea unei aplicații cu adevărat scalabile. Deși acest lucru este cu siguranță în afara domeniului de aplicare al acestei cărți, mecanismele de scalare a unei aplicații bazate pe vizualizare sunt, după cum am văzut, cu adevărat destul de simple.
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Care este cel mai bun mod de a indexa o vizualizare?

Deoarece o vizualizare este de fapt creată de o instrucțiune SQL, nu are niciun index propriu. Cu toate acestea, deoarece o vizualizare este întotdeauna creată local și este exclusivă pentru utilizatorul curent, crearea de indexuri pentru vizualizări nu este, în sine, problematică (cu condiția să vă amintiți să dezactivați tamponarea tabelului la crearea indexului). Consultați „Cum să indexați un tabel tamponat” în Capitolul 7 pentru mai multe informații despre acest subiect. Singura întrebare este dacă este mai bine să creați indexul înainte sau după ce populați vizualizarea.

Într-o oarecare măsură, aceasta depinde de cantitatea de date pe care vă așteptați să o aduceți în vizualizare și de unde sunt preluate acele date. De exemplu, pentru a descărca aproximativ 90 de înregistrări dintr-o instalare locală SQL Server într-o vizualizare și pentru a construi indecși pe două câmpuri, am obținut următoarele rezultate:

Deschideți Vizualizare și Populare = 0,042 sec

Vizualizare populată cu index = 0,003 sec

Timp total = 0,045 sec

Vizualizare deschisă și index = 0,033 secunde

Populare vizualizare indexată = 0,016 secunde

Timp total = 0,049 sec

După cum puteți vedea, aici există o mică diferență practică. Exact aceleași procese, din tabelul local echivalent Visual FoxPro, au dat următoarele rezultate:

Deschideți Vizualizare și Populare = 0,011 sec

Vizualizare populată cu index = 0,003 sec

Timp total = 0,014 sec

Vizualizare deschisă și index = 0,006 secunde

Populați vizualizarea indexată = 0,008 secunde

Timp total = 0,014 sec

Rezultatele de aici arată și mai puține diferențe. Folosirea de tabele mai mari, rularea într-o rețea sau utilizarea unei mașini cu hardware și configurații diferite vor influența timpul real. Cu toate acestea, în general, pare rezonabil să presupunem că ar trebui să construiți indecși după ce vizualizarea a fost populată. La urma urmei, indexarea unei vizualizări este întotdeauna o funcție pur locală, ceea ce nu poate fi spus pentru populația reală a vederii. În micul nostru exemplu, este clar că recuperarea datelor durează mai mult decât crearea indexurilor. Când utilizați vizualizări care sunt sub-seturi de date, acesta va fi, de obicei, cazul, astfel încât cu cât datele necesare pot fi recuperate mai repede, cu atât mai bine. Adăugarea de indexuri înainte de popularea vizualizării impune o suprasarcină asupra acestui proces și, în general, poate fi lăsată pentru mai târziu.
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Mai multe despre utilizarea vizualizărilor

Vizualizările sunt extrem de utile, fie că construiți o aplicație care urmează să fie rulată în întregime în Visual FoxPro, fie că trebuie să fie scalabilă, fie că trebuie doar rulată pe o sursă de date de la distanță. Cu toate acestea, ele necesită puțin mai multă gândire și o îngrijire suplimentară în utilizare. Această secțiune listează câteva lucruri suplimentare pe care le-am găsit când lucrăm cu vizualizări în general.

Utilizarea unei valori implicite pentru a deschide o vizualizare parametrizată

Mai devreme în acest capitol, am spus că atunci când utilizați o vizualizare parametrizată, cel mai bine este să vă asigurați că vizualizarea este deschisă fie cu o clauză explicită nodata, fie prin setarea proprietății nodataonload la .t. Cu toate acestea, această abordare înseamnă că deschiderea unei vizualizări necesită de fapt două interogări care să fie trimise la sursa de date. Prima interogare preia structura vizualizării, iar a doua interogare o populează. Este puțin probabil ca acest lucru să provoace întârzieri semnificative atunci când lucrați cu o vizualizare locală, chiar și într-o rețea relativ lentă. Cu toate acestea, de îndată ce începem să ne gândim la vederile de la distanță, un alt factor intră în joc. Pentru a maximiza performanța, nu dorim să trimitem mai multe interogări către back-end. Întrebarea este - cum putem evita să fie nevoie să recuperăm toate datele disponibile (ceea ce ar putea fi foarte mult!) și, de asemenea, să evităm temutul dialog „Introduceți o valoare pentru xxx” atunci când este inițializat un formular care utilizează o vizualizare parametrizată?

De fapt, Visual FoxPro necesită parametrul doar de două ori. În primul rând, atunci când o vizualizare este deschisă pentru prima dată și a doua de fiecare dată când o vizualizare este re-interogata. În orice alt moment, parametrul este irelevant deoarece aveți deja vizualizarea populată. Prin urmare, nu este nevoie să faceți parametrul disponibil la nivel global, cu condiția ca acesta să fie inițializat în orice metodă care va apela de fapt funcția requeryo. Soluția este, prin urmare, definirea explicită a unui parametru de valoare implicit în metoda OpenTables() a mediului de date. Cu toate acestea, acest lucru nu este atât de simplu pe cât ar părea la început. Formularul exemplu, DefParam.SCX, din codul care însoțește acest capitol, folosește o vizualizare parametrizată (lvcpybycity) și o inițializează pentru a prelua date pentru „Londra”, incluzând următoarele în metoda OpenTables() a mediului de date:

City_to_view = „Londra”

DODEFAULT()

NODEFAULT

Observați că atât DoDefault() cât și NoDefault sunt necesare aici din cauza modului în care interacțiunea dintre metoda OpenTables și evenimentul asociat BeforeOpenTables este implementată în Visual FoxPro - pare puțin ciudat, dar funcționează!

Folosind din nou o vizualizare

Am menționat deja că, pentru toate scopurile practice, puteți privi o vedere ca un tabel. Acest lucru ar trebui să însemne că puteți lansa o comandă USE <name> AGAIN pentru o vizualizare și într-adevăr puteți face acest lucru. Cu toate acestea, există o diferență între reutilizarea vizualizărilor și utilizarea tabelelor sau cursoarelor cu cuvântul cheie again. Când o vizualizare este utilizată din nou, Visual FoxPro creează un indicator către vizualizarea originală, mai degrabă decât să creeze un cursor complet nou, sau „deconectat”, pentru aceasta. Consecința este că, dacă modificați conținutul vizualizării originale, se modifică și conținutul aliasului alternativ. Pentru a fi sincer, nu suntem siguri dacă acesta este un lucru bun sau un lucru rău, dar în orice caz pare a fi o limitare a utilității opțiunii USE <view> AGAIN.

Este de remarcat faptul că, numai pentru vizualizările REMOTE, există și o opțiune NOREQUERY care poate fi utilizată cu comanda USE <view> AGAIN pentru a împiedica Visual FoxPro să reîncarce datele pentru vizualizare de pe serverul back-end.

Utilizarea datelor ca parametri de vizualizare

Din păcate, la momentul scrierii, există o eroare în Visual FoxPro Versiunea 6.0 (SP3), asociată cu setarea StrictDate, care afectează utilizarea datelor ca parametri pentru vizualizări. Când este specificată o setare pentru STRICTDATE, alta decât 0, nu există o modalitate simplă de a introduce un parametru de dată prin dialogul implicit. Singurul format care va fi acceptat este cel neechivoc: 1999,01,01, dar deși acesta va fi acceptat fără eroare, tot nu va da rezultatul corect atunci când se execută interogarea.

Acesta este încă un motiv pentru a nu folosi dialogul implicit pentru a aduna parametrii pentru vizualizări. Cu toate acestea, soluția este destul de simplă; trebuie doar să setați strictdate la 0 înainte de a deschide sau de a re-interoga o vizualizare folosind parametrii de dată, iar vizualizarea va accepta apoi parametrii în formatul normal de dată. Exemplul de cod pentru acest capitol include o vizualizare parametrizată (Iv campanelist) care necesită o dată. Următoarele fragmente arată rezultatul diferitelor moduri de furnizare a parametrului:

SETATI DATA STRICT LA 1

USE lv_campanelist

*** Introduceți în dialog: {12/12/1999}

*** Rezultat: Eroare de sintaxă!

*** Intrare in dialog: 12/12/1999

*** Rezultat: eroare 2032: constantă dată/date oră ambiguă

*** Intrare în dialog: 1999,12,12

*** Rezultat: Vizualizarea este populată cu TOATE datele, indiferent de valoarea introdusă

SETATI DATA STRICT LA 0

USE lv_campanelist

*** Intrare în dialog: 12/12/99

*** Rezultat: vizualizarea este completată corect cu date

Desigur, dacă inițializați parametrii în cod, nu este deloc nevoie să modificați strictdate. Deși trebuie totuși să vă asigurați că datele transmise ca parametri nu sunt ambigue, acest lucru se face cu ușurință folosind fie funcția DATE(aaaa,mm,zz) sau formularul {^aaaa-mm-zz} pentru a specifica valoarea.

Crearea vizualizărilor care implică mai multe tabele de căutare (Exemplu: LkUpQry.prg)

Am menționat mai devreme în acest capitol că View Designer are unele limitări atunci când vine vorba de construirea vederilor. Poate cea mai gravă dintre acestea este că designerul generează întotdeauna interogări folosind sintaxa „unire imbricată”, care pur și simplu nu poate face față interogărilor care implică anumite tipuri de relații. Acest lucru se vede clar atunci când încercați să construiți o vizualizare care include tabele legate la același tabel părinte, dar care nu sunt legate direct unul de celălalt. De obicei, astfel de legături apar în contextul tabelelor de căutare. Luați în considerare următoarea schemă:

Figura 9.5 Dialog de vizualizare a parametrilor

În acest design, tabelul părinte (Client) are un singur tabel copil (Adresă) care este utilizat pentru a stoca diferitele locații în care un anumit client își desfășoară afacerea. Fiecare înregistrare de adresă conține două chei străine, în plus față de cea a părintelui, care se conectează la tabelele de căutare pentru „Regiune” și „Tip de afaceri”. În mod clar, nu există o relație directă între aceste două căutări, dar este ușor de înțeles de ce ar fi necesar să se poată include descrierile relevante într-o vizualizare care oferă detalii despre un client.

Figura 9.6 arată configurația proiectantului de vizualizare pentru a crea o vizualizare a acestor tabele folosind condițiile de îmbinare oferite de designer ca implicite.

Figura 9.6 Designer de vizualizare pentru o vedere care implică tabele de căutare

Aceasta produce următoarea interogare:

SELECTează Customer.eusname, Address.address, Address.city, ;

Bustype.busdese, Région.regdesc;

DIN cap.09 ¡client INNER LOIN ch.09 ¡adresa ;

INNER LOIN ch09¡bustype;

INNER LOIN ch.09 ¡regiune ;

ON Region.regsid = Adresă .regkey ;

ON Bustype.bussid = Address.buskey ;

ON Customer.eussid = Adresa.euskey;

COMANDĂ DE Client.eusname, Adresă.oraș

Aceasta se alătură mai întâi Adresă clientului, apoi se alătură tipului de afaceri și, în sfârșit, regiune. Pare destul de rezonabil, nu-i așa? Cu toate acestea, rezultatele rulării acestei interogări par puțin ciudate (Figura 9.7):
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Figura 9.7 Rezultatele interogării

După cum puteți vedea, toți clienții sunt, aparent, în aceeași regiune. Și mai rău, atunci când încercăm să salvăm această vizualizare, apare un mesaj „Eroare 1806” care spune că:

„SQL: cheia de regulă pentru coloană nu a fost găsită

Poate avem nevoie de cheile din setul de rezultate pentru ca acest lucru să funcționeze? Dar nu, nici adăugarea câmpurilor cheie nu ajută. Poate că trebuie să specificăm Outer Joins în loc de lnner joins pentru tabelul de căutare? Din nou răspunsul este nu. În cele din urmă, în disperare, să încercăm să adăugăm tabelele într-o altă ordine. Mai întâi adăugați Adresa și cele două tabele de căutare. Creați interogarea și rulați-o. Totul arată bine! Acum adăugați în tabelul de clienți și alăturați-i. Reluați interogarea și acum, în loc de o singură regiune, obținem un singur client (și eroarea când încercăm să salvăm vizualizarea este că „Columna cuskey nu a fost găsită”).

Problema este că acest tip de interogare pur și simplu nu poate fi rezolvată într-o singură trecere folosind sintaxa „neted join” generată de designerul vizual. Pentru a face acest lucru, trebuie să construim două interogări - și acesta este motivul pentru care View Designer nu o poate face pentru noi.

Soluția „vizuală” este mai întâi să unești tabelul de adrese la tabelele sale de căutare (inclusiv cheia clientului) și să salvezi definiția vizualizării rezultată. Apoi, alăturați tabelului clienți la această vizualizare. (Rețineți că o vizualizare poate include alte vederi în definiția sa.) Vederile Iv AddLkup și Iv CustAddress din exemplul de cod pentru acest capitol arată rezultatele intermediare și finale ale acestei abordări (Figura 9.8):

Cusname 	1AdresăICityIBusdescIRegdesc
Dewey, Cheetam și Howe 	¡ 4029 Groenlanda¡AmhersLNYi Contabilitate/Consiliere financiară¡Nordul SUA
Dewey, Cheetam și Howe 	¡4029 Groenlandele¡AmhersLNY¡ Drept civil/penal¡Nordul SUA
Dewey, Cheetam și Howe 	¡ 4823 Main Street¡ Boston, MA¡ Drept civil/penal" Nordul SUA
Dewey, Cheetam și Howe 	¡4823 Main Street¡ Boston, MA= Administrare imobiliară/proprietăți. nordul SUA
Doolittle & Dalley 	¡1 4 Connor Street¡ Dublin¡ Real Estate/Property MgtBntish Isles (Marea Britanie și Irlanda)
Doolittle & Dalley 	¡12 Someplace Crescent¡ Londra¡Real Estate/Property MgtBritish Isles (Marea Britanie și Irlanda)
Doolittle & Dalley 	И 233 Rue St Garde: Paris= Administrare imobiliară/proprietăți[Europa de Nord
Letcher și Scorar 	¡789 Crosslands Drive\Quebec¡Management/Consultanță generală■ Canada
Letcher și Scorar 	¡789 Crosslands DriverQuebec¡Software Developmentr Canada
Letcher and Scorer 	¡ 3444 Longshore Boulevard¡ Victoria¡Management/Consultanță generală¡Canada
Letcher and Scorer 	¡ 3444 Longshore Boulevard\ Victoria¡Dezvoltare software¡Canada

Figura 9.8 Rezultatul corect în sfârșit!

Acest lucru va da rezultatele corecte și, deși este o abordare destul de lungă, este singura modalitate pe care o cunoaștem de a rezolva corect problema folosind designerul de vizualizare. Desigur, soluția este ușor de gestionat dacă creați definiția vizualizării în cod. Puteți utiliza fie sintaxa SQL standard, după cum urmează:

*** Sintaxa standard de interogare

SELECT CU.cusname, AD.address, AD.city, BU.busdesc, RG.regdesc;

DE LA client CU, adresa AD, tip autobuz BU, regiune RG;

UNDE AD.cuskey = CU.cussid ;

SI BU.bussid = AD.buskey;

AND RG.regsid = AD.regkey;

ORDENAȚI DUPĂ cusname, oraș

sau, dacă preferați să utilizați formatul ANSI 92, puteți utiliza „uniuni secvențiale”, astfel:

SELECT CU.cusname, AD.address, AD.city, BU.busdesc, RG.regdesc;

FROM client CU JOIN adresa AD ON AD.cuskey = CU.cussid ;

JOIN bustype BU ON BU.bussid = AD.buskey ;

JOIN région RG ON RG.regsid = AD.regkey ;

ORDENAȚI DUPĂ cusname, oraș

Aceste interogări sunt incluse în LkUpQry.prg în exemplul de cod, dar dacă doriți să utilizați sintaxa de îmbinare imbricată, ne temem că sunteți pe cont propriu! Deși este posibil, în anumite situații, ca interogări de acest tip să funcționeze folosind sintaxa de îmbinare imbricată, nu merită efortul (cu excepția cazului în care vă plac cu adevărat cuvintele încrucișate). Există modalități mai simple și mai fiabile de a rezolva problema. Oricare

abordarea pe care o adoptați, probabil că veți ajunge să codificați singur astfel de vederi, mai degrabă decât să utilizați View Designer.

Crearea de vederi parametrizate care necesită liste de parametri

O altă limitare majoră a proiectantului de vederi este că nu poate crea o vizualizare parametrizată care să accepte corect o listă de parametri. De fapt, situația este și mai rea deoarece, deși puteți codifica o astfel de vizualizare parametrizată, nu puteți specifica parametrii prin intermediul casetei de dialog într-un mod care să fie semnificativ pentru motorul SQL. Singura soluție pe care am reușit să o găsim (până în prezent) este să codificăm manual vizualizarea și să folosim substituția macro pentru parametru. SQL-ul arată astfel:

CREATE SQL VIEW IvCityList AS ;

SELECTAȚI clicmpy, clicity, cliphon ;

DE LA clienți ;

WHERE INLIST( clicity, &?city_list )

Când deschideți (utilizați) vizualizarea pe care o creează acest cod, lucrurile par promițătoare - apare dialogul implicit care cere o valoare pentru „city lisf. Deci, introduceți o listă, dar cum? Ei bine, funcția INLIST() se așteaptă ca valorile să fie separate prin virgule, iar fiecare valoare trebuie să fie între ghilimele, așa că ceva de genul acesta ar trebui să fie bine:

„Londra”, „Berlin”, „Stuttgart”

Făcând clic pe butonul „OK” al casetei de dialog după introducerea acestui șir, apare imediat eroarea 1231 („ Operand lipsă”). De fapt, ORICE valoare pe care o introduceți provoacă această eroare și (evident) interogarea nu populează vizualizarea. Cu toate acestea, dacă specificați aceeași listă de valori și le stocați mai întâi în parametrul de vizualizare, astfel:

city_list = „„Londra”, „Berlin”, „Stuttgart””

vizualizarea va funcționa după cum este necesar. Pentru a fi perfect sincer, nu suntem siguri de ce dialogul nu poate fi folosit pentru a popula parametrul în acest scenariu, dar în mod clar există o problemă cu modul în care este interpretată intrarea din dialogul implicit atunci când SQL-ul este executat. Soluția, dacă aveți nevoie de această funcționalitate, este pur și simplu să evitați View Designer și să evitați (din nou) dialogul implicit pentru adunarea parametrilor pentru interogare.

Un ultim cuvânt despre designerul vederii

Să repetăm avertismentul pe care l-am dat mai devreme despre utilizarea designerului de vizualizare. Dacă utilizați vizualizările pe care le-ați creat în cod, vă recomandăm insistent să le denumiți diferit de cele pe care le creați în designer, pentru a evita modificarea vizuală a unei astfel de vederi. Dacă încercați și faceți acest lucru, sunt șanse să vă distrugeți complet vizualizarea, deoarece designerul va rescrie definiția folosind sintaxa de îmbinare imbricată, care, după cum am văzut deja, poate să nu fie adecvată.

Deci designerul este cu adevărat de folos? Da, desigur că este. Pe de o parte, este mult mai ușor, chiar și pentru o vizualizare despre care știți că va trebui să codificați manual, să utilizați designerul pentru a colecta tabelele relevante, a obține lista de câmpuri selectate, condițiile de bază de aderare, filtrele și criteriile de actualizare. Utilizați designerul pentru a crea vizualizarea, dar copiați SQL-ul pe care îl produce în propriul fișier de program în același timp. Apoi utilizați GenDBC.prg pentru a obține tot codul de configurare asociat pentru vizualizare și adăugați-l și la programul dvs. de creare. În cele din urmă, editați SQL-ul real pentru a elimina îmbinările imbricate și pentru a regenera vizualizarea „corect”.
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SQL în Visual FoxPro

Indiferent dacă construiți aplicații de bază de date sau componente de nivel mediu, sau căutați un front end pentru o bază de date la distanță, poate cel mai important motiv pentru a utiliza Visual FoxPro este motorul său SQL integrat. Multe instrumente pot folosi SQL, dar puține au combinația unei baze de date native, motor SQL încorporat și programare GUI, ceea ce face ca Visual FoxPro să fie atât de flexibil și puternic. În această secțiune vom acoperi câteva dintre lucrurile pe care le-am învățat (deseori pe calea grea) despre utilizarea SQL. Exemplul de cod pentru acest capitol include o bază de date separată (SQLSAMP.DBC) care conține tabelele utilizate în exemplele pentru această secțiune.
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Îmbinarea tabelelor (Exemplu ExJoins.prg)

Una dintre cele mai binevenite schimbări în Visual FoxPro a fost introducerea, în Visual FoxPro 5.0, a suportului pentru un set complet de join. Acest lucru a eliminat efectiv, pentru majoritatea dezvoltatorilor, necesitatea de a lupta cu comanda sindicală destul de greoaie (ca să nu spunem de-a dreptul persnickety), care anterior fusese singura modalitate de a gestiona orice altceva decât o simplă „Inner Join”. Prin urmare, vom începe discuția despre utilizarea SQL cu o scurtă trecere în revistă a diferitelor tipuri de unire care sunt disponibile și a sintaxei pentru implementarea lor înainte de a trece la alte chestiuni.

Tabelul 9.1 (mai jos) listează cele patru tipuri de unire care pot fi specificate în instrucțiunile SQL în Visual FoxPro. Sintaxa de bază care trebuie utilizată în toate cazurile este:

SELECTAȚI <câmpuri> DIN <tabel1> <TIP DE JOIN> <tabel2> ON <condiție>

Unde <tipul de alăturare> poate fi oricare dintre cele enumerate în prima coloană a tabelului:

Tabelul 9.1 Tipuri de conectare SQL în Visual FoxPro

Tipul de alăturare 	Include în setul de rezultate
Inner Join 	Numai acele înregistrări ale căror chei se potrivesc în ambele tabele
Left Outer Join 	Toate înregistrările din primul tabel plus înregistrările care se potrivesc din al doilea
Right Outer Join 	Înregistrările care se potrivesc din primul tabel plus toate înregistrările din al doilea
Unire completă 	Toate înregistrările din ambele tabele, indiferent dacă există potriviri

Programul ExJoins.prg rulează aceeași interogare simplă împotriva aceleiași perechi de tabele de patru ori, folosind o condiție de îmbinare diferită de fiecare dată. Rezultatele reale sunt prezentate în Figura 9.9, iar numărul de rânduri returnat de fiecare tip de interogare a fost:

Unire completă (stânga sus): 14 rânduri

Îmbinare interioară (stânga jos): 9 rânduri

Îmbinare exterioară din dreapta (dreapta sus): 10 rânduri

Left Outer Join (dreapta jos): 13 rânduri

Figura 9.9 Asocieri diferite produc rezultate diferite din aceleași date

Observați că pentru fiecare condiție, cu excepția Inner Join, există cel puțin un rând care conține o valoare NULL în cel puțin o coloană. Acesta este ceva care trebuie luat în considerare în cod (sau formulare) care se bazează pe îmbinări externe sau complete. După cum am menționat deja, valorile NULL se propagă în Visual FoxPro și pot provoca rezultate neașteptate dacă apariția lor nu este gestionată corespunzător.
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Construirea de interogări SQL

Deși există de obicei cel puțin două moduri de a face lucrurile în Visual FoxPro, în acest caz există trei! Puteți utiliza sintaxa SQL „standard” care utilizează o clauză unde pentru a specifica atât îmbinările, cât și condițiile de filtrare, sau puteți utiliza sintaxa mai nouă „ANSI 92”, care implementează îmbinări folosind clauza join...on și folosește o clauză where pentru specificați filtre suplimentare. Sintaxa ANSI 92 are două moduri de a specifica îmbinările, fie „secvențial” fie „imbricat” și fiecare are avantajele și dezavantajele lor.

Următoarea interogare folosește sintaxa SQL standard pentru a efectua o îmbinare interioară pe trei tabele în care numele clientului începe cu litera „D” și ordonează rezultatul:

SELECTAȚI CL.cliname, CO.consname, CO.confname, PH.phnnum, CO.conemail;

DIN sqlcli CL, sqlcon CO, sqlpho PH ;

UNDE CL.clisid = CO.clikey ;

AND CO.consid = PH.conkey ;

ȘI CL.cliname = "D" ;

ORDER BY clinam, consname

Observați că nu există o distincție clară între condițiile de „alăturare” și „filtrare”. Interogarea echivalentă care utilizează sintaxa „unire secvențială” este puțin mai clară, deoarece îmbinările și condițiile lor sunt separate de condiția de filtru:

SELECT CL.cliname, CO.consname, CO.confname, PH.phnnum, CO.conemail ;

FROM sqlcli CL ;

INNER JOIN sqlcon CO ON CL.clisid = CO.clikey ;

INNER JOIN sqlpho PH ON CO.consid = PH.conkey ;

UNDE CL.cliname = "D" ;

ORDER BY clinam, consname

Formatul „unire imbricată” face și mai ușoară separarea îmbinărilor de condițiile lor. Este important de remarcat că în această sintaxă, îmbinările și condițiile lor sunt procesate din exterior în interior. Astfel, în următoarea interogare, prima îmbinare care urmează să fie procesată adaugă tabelul 'sqlcon' folosind ultima condiție 'on'; următorul care urmează să fie procesat adaugă „sqlpho” folosind penultima condiție „por”. Orice alăturare suplimentară va fi procesată în același mod:

SELECTAȚI CL.cliname, CO.consname, CO.confname, PH.phnnum, CO.conemail;

FROM sqlcli CL ;

INNER JOIN sqlcon CO ;

INNER JOIN sqlpho PH ;

ON CO.consid = PH.conkey ;

ON CL.clisid = CO.clikey;

UNDE CL.cliname = "D";

ORDER BY clinam, consname

Amintiți-vă că toate aceste trei interogări produc de fapt aceleași rezultate - alegerea stilului, cel puțin în acest caz, este doar una de preferință personală. Cu toate acestea, deși stilul poate să nu conteze, ordinea în care specificați îmbinările contează cu siguranță de îndată ce utilizați fie formatul imbricat, fie cel secvenţial. Schimbarea ordinii în care sunt specificate îmbinările poate modifica rezultatul și chiar împiedica rularea interogării. (Inversarea secvenței din a doua ilustrație provoacă o eroare „Alias CO nu s-a găsit deoarece tabelul „sqlcon” nu a fost încă conectat la interogare.) Sintaxa standard are avantajul în acest sens deoarece toate tabelele necesare sunt specificate mai întâi. Ordinea în care sunt listate îmbinările nu afectează rezultatul și puteți chiar să amestecați îmbinări și filtre fără a afecta negativ rezultatul.

În timp ce stilul imbricat este folosit pentru a genera SQL-ul produs de designerii Visual FoxPro View și Query, am văzut deja că există unele tipuri de relații care nu pot fi gestionate cu ușurință de acest format. Din câte știm, nu există condiții pe care stilul imbricat să le poată face față și stilul secvențial să nu le poată face și acesta este, prin urmare, stilul nostru preferat.

Există, totuși, o limitare a implementării sintaxei ANSI 92 în Visual FoxPro. Este restricționat la maximum nouă unități. Acum poate fi doar o coincidență că Visual FoxPro are și o limită de nouă uniuni într-o singură instrucțiune select. Sau s-ar putea ca modul în care este implementată de fapt sintaxa să fie prin realizarea unei uniuni „în spatele scenei”? În orice caz, acest lucru limitează numărul maxim de tabele care pot fi adresate la zece, dar este o limitare care, din câte putem determina, se aplică numai dacă utilizați sintaxa bazată pe join.
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Cum să verificați rezultatele unei interogări (Exemplu ChkQry.prg)

Cum putem spune dacă o interogare SQL a returnat de fapt ceva? La urma urmei, instrucțiunea de interogare în sine nu generează o valoare returnată. Răspunsul este că există mai multe moduri și fiecare are avantajele și dezavantajele sale. Pe care o utilizați de fapt, va depinde de tipul de interogare pe care o executați și de destinația către care este direcționată rezultatul.

Folosind Reccount()

Poate cel mai evident lucru de verificat este numărul înregistrărilor din tabelul sau cursorul de ieșire. Visual FoxPro are o funcție standard, RECCOUNT('AliasName'), care returnează numărul de înregistrări din setul de înregistrări specificat fără a fi nevoie chiar să selecteze zona de lucru (deși rezultatul normal al rulării unei interogări SQL este schimbarea zonelor de lucru oricum) . Cu toate acestea, acesta nu este un ghid infailibil din mai multe motive:

® RECCOUNT() returnează întotdeauna numărul de înregistrări fizice dintr-un tabel, cursor sau vizualizare. Cu alte cuvinte, ignoră setarea steagului șters pe o înregistrare. Singura dată când RECCOUNT () se modifică este atunci când o înregistrare nouă este adăugată la tabel sau când tabelul este împachetat pentru a elimina înregistrările șterse.

• 	Dacă rezultatul unei interogări este o vizualizare filtrată a datelor originale, beccounto returnează numărul de înregistrări din tabelul de bază (sau cursorul sau vizualizarea) care a fost interogat. Această problemă specială poate fi evitată forțând Visual FoxPro să creeze întotdeauna un cursor fizic pentru o interogare prin includerea clauzei NOFILTER.

• 	reccount () își obține informațiile din antetul tabelului și nu efectuează de fapt o numărare a numărului de înregistrări din setul de rezultate. Deși este puțin probabil să fie greșit, este posibil să nu vă ofere informațiile de care aveți nevoie în fiecare situație. De exemplu, dacă aveți înregistrări care conțin numai valori nule - este acesta într-adevăr un rezultat valid pentru o interogare?

• 	reccount () este aplicabil numai dacă destinația de ieșire a interogării este un cursor sau un tabel. Dacă creați o matrice, este inutil.

Folosind _TALLY

A doua metodă pentru a determina dacă o interogare a returnat ceva este utilizarea variabilei de sistem _tally. Cu toate acestea, deși este cu siguranță adevărat că _tally vă va spune câte înregistrări au fost returnate de o interogare, este important să rețineți că _tally este, de asemenea, setat de o serie de alte comenzi. Suntem, încă o dată, datori neobositelor Tamar Granor și Ted Roche și „Ghidului hackerilor”, pentru a stabili lista definitivă a unor astfel de comenzi:

• 	Adăugați din mediu necompletat Calculați Copierea către

• 	Copy To Array Count Delete Delete-SQL Export

• 	Rechemare pachet de index Reindexare Înlocuire

• 	Înlocuire din matrice Selectare-SQL Sortare Sumă Actualizare-SQL

_tally raportează numărul de rânduri returnate, indiferent de destinația de ieșire, dar trebuie să subliniem că este cu adevărat de încredere numai dacă este testat imediat după ce interogarea SQL a fost executată. Să te bazezi pe păstrarea valorii sale nu este sigur și așa că, dacă crezi că va trebui să știi mai târziu ce a returnat o anumită interogare, stocați întotdeauna valoarea într-o variabilă imediat.

Alte două avertismente cu privire la utilizarea _tally. În primul rând, vă va spune doar numărul de înregistrări care s-au calificat pentru includerea în setul de rezultate. Nu înseamnă că toate înregistrările conțin valori valide. În al doilea rând, dacă executați o interogare care include un numărător, amintiți-vă că astfel de interogări returnează întotdeauna cel puțin o înregistrare - chiar și atunci când rezultatul este zero.

Folosind SELECT COUNT()

Acesta este cu siguranță cel mai fiabil mod de a obține numărul de înregistrări dintr-un tabel sau cursor. În plus, există două moduri distincte de numărare a înregistrărilor. Folosind select count(*), obțineți numărul de înregistrări, indiferent de conținutul lor (adică este identic cu _tally); dar prin specificarea unui anumit câmp de numărat, limitați rezultatul pentru a include numai acele înregistrări în care câmpul specificat nu este NULL.

Cu toate acestea, la fel ca RECCOUNT() , aceasta poate fi folosită numai atunci când o interogare își direcționează ieșirea către un cursor fizic sau un tabel. Dacă rezultatul este o vizualizare filtrată, singura modalitate de a utiliza select counto este împotriva tabelului de bază - și rezultatul este, prin urmare, inutil.

Programul de testare (ChkQry.prg) arată rezultatul utilizării reccount(), _tally și select counto în diferite situații. În primul rând, pentru o interogare care implică o îmbinare exterioară care returnează unele înregistrări cu valori nule. În al doilea rând, rulând aceeași interogare de două ori - o dată când creează o vizualizare filtrată și din nou pentru a produce un cursor fizic.

Tabelul 9.2 RECCOUNT(), _TALLY și SELECT COUNT() pot diferi

Query 	Reccount()_TallyCount(*)Count(<câmp>)
Outer Join - 13 Records, 4 with Nulls 	1313139

I_______________________________________________________________________________________________________Il_________________________________________________Il_______________________Il_____________________________Il________________________________________________I

Interogarea produce o vizualizare filtrată (2 înregistrări se califică) 	9299
Repetați ultima interogare într-un cursor fizic (2 înregistrări) 	2222
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Cum se extinde un cursor generat SQL

În timp ce SQL este considerat în mod normal ca oferind o metodă de extragere a datelor dintr-un tabel sau un set de tabele existent, este perfect posibil să redenumiți, sau chiar să creați și să populați coloanele într-un cursor generat. Metoda de a face acest lucru depinde de ceea ce doriți ca rezultat. Următoarele secțiuni ilustrează câteva dintre tehnicile care pot fi utilizate pentru a aborda diferite probleme.

Definirea coloanelor noi

Metoda standard pentru definirea unei noi coloane este de a include o valoare constantă a tipului de date adecvat în clauza de câmpuri a unei instrucțiuni SELECT și de a utiliza cuvântul cheie „AS” pentru a defini un nume pentru coloană.

Notă: De fapt, Visual FoxPro nu necesită deloc includerea cuvântului cheie „AS” și nici majoritatea serverelor back-end. De fapt, unele versiuni mai vechi de servere nu acceptă deloc cuvântul cheie „AS” și includerea acestuia într-o interogare trimisă unui astfel de back-end provoacă o eroare „Nume coloană nevalid”. Din fericire, standardul pare să fie că, chiar și atunci când nu este necesar, includerea „AS” nu provoacă o eroare. Nu există nicio îndoială că îmbunătățește lizibilitatea unei interogări, iar utilizarea sa este, credem, amplu justificată numai din aceste motive.

Singurul lucru posibil! Iată că atunci când specificați constantele pentru noile coloane, trebuie să vă asigurați că definiți valori suficient de mari pentru ca acestea să rețină datele. De exemplu, definirea unei noi coloane de caractere ca „spacecd” va face exact asta - creați o coloană de tip caracter cu o lățime de un caracter. În mod similar, o coloană definită ca „0.0” va crea o coloană numerică a cărei definiție este N (3,1), în timp ce pur și simplu specificând „0”, în loc să creeze un tip de date întreg, creează o coloană numerică de dimensiuni (1,0). Desigur, pentru acele tipuri de date (Currency, Data, DateTime și Logic) care sunt predefinite, nu există nicio problemă. O listă completă a tipurilor de date standard și a constantelor lor de inițializare corespunzătoare este dată în Tabelul 9.3 de mai jos.

Tabelul 9.3 Constante pentru inițializarea coloanelor noi

Tip de date Necesar 	Inițializare cu...
Caracter 	SPACE( n )
Numeric 	Câte zerouri sunt necesare, includeți virgulă zecimală dacă este necesar
	

Moneda 	Fie $0, fie NTOM(0)
logic 	.T. sau .F. Asa Potrivit
Data 	{} sau o dată
DateTime 	{/:} sau DTOT( {} ) sau un DateTime()
Alte tipuri de date 	Alăturați necondiționat un cursor (sau un tabel) cu doar câmpuri obligatorii și o singură înregistrare goală

Adăugarea unui tip de date nestandard

Deși puteți defini o valoare constantă pentru toate tipurile de date de bază acceptate de Visual FoxPro, nu există valori „constante” pentru unele dintre celelalte tipuri de date (de exemplu, memo, întreg, float, dublu etc). Cea mai bună soluție pe care o cunoaștem este să creăm un cursor fals care constă dintr-un câmp (sau câmpuri) de tipul dorit și să aibă o singură înregistrare în el. Acest cursor poate fi apoi alăturat celorlalte tabele utilizate într-o interogare, iar setul de rezultate va include un câmp gol de tipul adecvat, așa cum este ilustrat mai jos pentru câmpurile Memo și Integer:

CREATE CURSOR memodummy ( memofield M(4) , intfield I(4) )

Adăugați spațiu liber în memoriu

SELECT SQLCLI.*, MEMODUMMy.memofield AS CliNotes, MEMODUMMy.intfield AS CliInt ;

FROM sqlcli ;

JOIN memoriu ON 1=1;

ÎN CURSOR CurMemTest

Observați că, deoarece folosim sintaxa join...on, trebuie să specificăm o condiție on. În acest caz, dorim ca fiecare înregistrare din setul de ieșire să aibă câmpuri suplimentare, așa că am specificat o condiție care se evaluează întotdeauna la adevărat. (De ce nu folosim doar „=.t.”? În cazul în care trebuie să comunicăm cu un server back-end care nu acceptă câmpuri logice. Orice motor SQL va interpreta „unde 1=1” ca fiind TRUE și „unde 0=1” ca fals). Folosind sintaxa SQL standard, nu este nevoie de un astfel de truc și echivalentul SELECT este pur și simplu:

SELECT SQLCLI.*, MEMODUMMy.memofield AS CliNotes, MEMODUMMy.intfield AS CliInt ;

FROM sqlcli, memodummy ;

INTO CURSOR memtest

Faceți actualizabil un cursor generat de SQL

Dacă adăugați câmpuri goale la un cursor generat de SQL, probabil că doriți să inserați niște valori în ele. Cu toate acestea, cursorul generat ca rezultat al unei interogări SQL este întotdeauna Read-Only. Cea mai simplă modalitate de a face un astfel de cursor actualizabil este să emiti din nou un USE DBF( 'cursor alias' ). Dar acest lucru va funcționa numai atâta timp cât cursorul nu este doar o vizualizare filtrată a datelor subiacente. Adăugarea unei clauze NOFILTER la un SQL asigură că Visual FoxPro trebuie să creeze un cursor fizic pentru setul de rezultate și nu doar să genereze o vizualizare filtrată. Următorul exemplu creează un cursor actualizabil care conține ambele câmpuri din tabelul sursă și o coloană nouă:

SELECTAȚI SQLCLI.*, SPACE(12) AS NewField ;

FROM sqlcli ;

INTO CURSOR junk NOFILTER

UTILIZAȚI DIN NOU DBF('junk') ÎN 0 ALIAS UpdCur

UTILIZAȚI ÎN junk

SELECT updCur

Concatenarea câmpurilor de caractere (Exemplu: concat.prg)

Din păcate, nu există o modalitate ușoară de a concatena câmpuri de caractere într-o interogare SQL. În rapoarte, puteți folosi virgulele pentru a decupa câmpurile care trebuie concatenate (și punct și virgulă pentru a adăuga întreruperi de linie), dar care nu vor funcționa într-o interogare. Cel mai apropiat Visual FoxPro de un „operator” pentru a concatena două șiruri de caractere este semnul minus („-”). Cu toate acestea, acest lucru doar reduce spațiile de sfârșit din primul câmp și adaugă întregul al doilea câmp (nedecupat) la rezultat. Astfel, având în vedere două câmpuri definite ca Caracter (10), rezultatul va fi următorul:

F1 => "Fred"

F2 => "Smith"

(F1-F2) => "FredSmith"

ceea ce nu este exact ceea ce ne-am dori în mod normal. Singura alternativă realistă este să folosiți funcții de tăiere explicite în jurul câmpurilor care urmează să fie concatenate și să includeți orice punctuație sau spații necesare în mod explicit în SELECT. Deci, pentru a genera un câmp de nume cu aspect normal din cele două câmpuri de mai sus, ar trebui să facem una dintre următoarele:

SELECTAȚI ( ALLTRIM(F1) + " " + ALLTRIM(F2) ) AS Nume Complet

SELECTAȚI ( ALLTRIM(F2) + ", " + ALLTRIM(F1) ) AS SortName

Nu foarte elegant, dar eficient. Există, totuși, o problemă! stând la pândă aici. Dacă unul dintre câmpuri este nul, rezultatul concatenat este, de asemenea, nul. Nu putem explica acest comportament. La urma urmei, încercarea de a concatena un câmp de caractere cu un nul generează în mod normal o eroare de „nepotrivire tip de date”. Nu putem vedea de ce simpla adăugare a unui mxtrimo ar trebui să schimbe acest comportament, dar o face și poate fi foarte dificil de depanat atunci când se întâmplă. Următorul program creează un set de rezultate care ar trebui să conțină un șir formatat format din numele companiei și un nume de contact:

**************************************************** ********************

* Program.

: ConCat.prg

* Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* Rezumat...: Ilustrați problema concatenării șirurilor de caractere

..........: 	Când unul sau altul conține valori NULL

*** Generați un cursor care conține valori NULL pentru consname

SELECT CL.eliname, CO.consname ;

DIN sgleli CL ;

LEFT OUTER JOIN sglcon CO ;

ON CO.clikey = CL.clisid ;

ORDER BY dinante, consname ;

INTO CURSOR lojoin

*** Creați o ieșire formatată

SELECT ( ALLTRIM( dinante ) + " CONTACT: " + ALLTRIM( consname ) ) ; din lojoin ;

INTO CURSOR Formatat NOFILTER

Setul de rezultate de la prima interogare arată astfel:

Cliname

Consname

Bloguri Bridgestone/Firestone	
Băutură Bridgestone/Firestone	
Dewey, Cheetum și Howe Legal Services 	Cash
Dewey, Cheetum și Howe Legal Services 	T rubla
Doolittle și Dalley 	ÑIJLL.
Eufonie 	ÑIJLL.
Consilier Foxpro 	Graystoke
Joe's Diner 	ÑIJLL.
Microsoft 	ÑIJLL.
Tightline Computers, Ltd. 	Akins
Tightline Computers, Ltd. 	Kramek
Tremco, Inc 	Bracale
Tremco, Inc 	Salvatore

Figura 9.10 Set de rezultate intermediare

Dar al doilea arată așa:

eu	
Bridgestone/Firestone CONTACT: Bloç	

Bridgestone/Firestone CONTACT: Bea

Servicii juridice Dewey, Cheetum și Howe CONTACT: Numerar

Servicii juridice Dewey, Cheetum și Howe CONTACT: Probleme NLLL.............................. ..

Consilier Foxpro CONTACT: Graystoke

NLLL.................................................

iJïjZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

Tightiine Computers, Ltd. CONTACT: Akins

Tightline Computers, Ltd. CONTACT: Kramek

Tremco, Inc CONTACT: Bracale

Tremco, inc CONTACT: Salvatore

Figura 9.11 Setul final de rezultate - complet cu valori NULL

Observați că valorile nule s-au propagat în setul de rezultate final! Acesta este încă un exemplu de cât de important a devenit, în Visual FoxPro, să fim conștienți de posibilitatea ca valorile nule să apară ca rezultat al utilizării Outer Joins. Din fericire, soluția este destul de simplă. Trebuie doar să modificăm a doua selecție pentru a înlocui un șir de caractere gol dacă oricare dintre valori este nulă, iar funcția NVL () face acest lucru pentru noi:

*** Creați o ieșire formatată

SELECTARE ( ALLTRTM( NVL(cliname, "") ) + " CONTACT: " ;

+ at.t.trtm( NVL( consname,"") ) );

FROM lojoin ;

CURSOR TNTO Formatat NOFTLTER

Această versiune modificată va asigura, cel puțin, că vedem toate numele companiilor, tocmai de aceea am folosit o îmbinare exterioară stângă în primul rând.

Efectuarea calculelor (Exemplu: SQLCalc.prg)

De multe ori trebuie să efectuăm calcule pe datele pe care le extragem folosind interogări, așa că se pune întrebarea dacă este mai bine să facem astfel de calcule ca parte a interogării sau să postprocesăm setul de rezultate și să facem calculele în afara. Nu există un răspuns greu și rapid, dar, dacă calculul este relativ simplu, iar setul de date care urmează să fie procesat nu este prea mare, suprasolicitarea interogării nu ar trebui să fie semnificativă. Problema cu postprocesarea unei interogări este că va trebui să faceți setul de rezultate citit/scris, deci sunt implicați de fapt trei pași - interogarea inițială, crearea cursorului de citire/scriere și procesul în sine . Singura soluție reală este să încerci în ambele moduri în fiecare caz și să vezi care funcționează cel mai bine în situația ta particulară.

Efectuarea calculelor în interogare nu este dificilă, deși trebuie să vă amintiți câteva reguli de bază. În primul rând, câmpul care va stoca rezultatul calculului ar trebui să fie denumit și formatat corespunzător. În al doilea rând, nu vă puteți referi la un câmp calculat nici în lista de câmpuri, nici în condițiile de filtrare. Orice astfel de referință va genera o eroare. Prin urmare, următoarea clauză select este invalidă:

SELECT SUM( invamt ) AS totalinv, ;

SUM( invpaid ) AS totalpaid, ;

(totalinv - totalpaid) AS invbal ;

Includerea condiționată a câmpurilor într-un set de rezultate

Funcția Visual FoxPro Immediate IF (tifo) poate fi utilizată într-o interogare pentru a extrage condiționat date din oricare dintre cele două câmpuri într-un singur câmp. Cu toate acestea, există o suprasarcină asociată cu aceasta și semnificația acelei cheltuieli generale va depinde de natura stării și de numărul de înregistrări care trebuie procesate, deoarece testul va fi aplicat fiecărei înregistrări. Ca și în cazul efectuării calculelor, singura modalitate de a afla dacă aceasta va fi o problemă este să testați temeinic volumele realiste de date.

Sintaxa de utilizare este exact așa cum v-ați aștepta. Următoarea selecție primește conținutul unuia sau altuia dintre cele două câmpuri, în funcție de valoarea unui al treilea:

SELECTIȚI IIF(tip = „Rezidențial”, Cod de rezidență, Cod de afaceri ) Tip AS

Conversia câmpurilor de la un tip de date la altul (Exemplu: SQLConv.prg)

O cerință foarte comună este extragerea datelor dintr-o bază de date într-un alt format, de obicei ca text pentru transferul într-o altă aplicație. Visual FoxPro a oferit întotdeauna o serie de funcții care pot gestiona conversia de la diferite tipuri de date la echivalentele lor șir de caractere ( STR(), DTOC() și așa mai departe). Acestea pot fi folosite în interogări pentru a converti datele din tipul original în șirul de caractere corespunzător.

Visual FoxPro Versiunea 6.0 a adăugat o nouă funcționalitate la funcția TRANSFORMO, astfel încât, dacă este utilizată pe o expresie, fără a specifica coduri de formatare, să fie efectuată o conversie implicită a datelor în echivalentul său șir. Acest lucru simplifică foarte mult sarcina de conversie a datelor în șiruri de caractere și este într-adevăr o schimbare binevenită. Pentru detalii complete despre capabilitățile (și limitările) acestei funcții, consultați fișierul de ajutor online, dar funcționalitatea de bază pentru crearea unui cursor care conține doar date de caractere dintr-un tabel poate fi acum foarte ușor furnizată după cum urmează:

*** Extrageți informații brute despre client/factură

SELECT TRANSFORM( CL.cliname ) AS clinam, ;

TRANSFORM(IN.invdate) AS invdate, ;

TRANSFORM( IN.invamt ) AS invamt, ;

TRANSFORM(IN.invpaid) AS plata, ;

TRANSFORM ( invamt - invpaid ) AS invbal ;

FROM sqlcli CL ;

JOIN sqlinv IN ON IN.clikey = CL.clisid ;

COMANDA PENTRU Cliname ;

INTO CURSOR curNumeric

Observați că TRANSFORM() a convertit valorile în numere întregi și a formatat dimensiunile câmpurilor în consecință, ceea ce produce un cursor cu următoarea structură:

CLINAME Personajul 40

INVDATE Personajul 8

Personaj INVAMT 3

PLATA Caracterul 3

INVBAL Caracter 1

Din pacate este GRESIT! Aceasta este o problemă comună! care vă poate împiedica oricând permiteți lui Visual FoxPro să determine dimensiunea unui câmp care este creat într-un set de rezultate. Visual FoxPro bazează întotdeauna dimensionarea câmpului pe prima valoare pe care o extrage și apoi aruncă toate celelalte date în același câmp - în acest caz trunchiind datele pentru a se potrivi. Așa că am pierdut de fapt date aici din cauza primei

factura procesată s-a întâmplat să aibă un sold de 0,00 care, după ce a fost transformat, are ca rezultat un singur caracter „0”, determinând la rândul său lățimea coloanei generate. Următorul record ar trebui să aibă un sold de 622,00, dar acum apare ca „6”.

În mod similar, dacă am dori să convertim datele în, să zicem, format de monedă, am putea pur și simplu să încapsulăm o funcție ntomo în jurul fiecărei expresii. Dar acest lucru ar produce un cursor cu următoarea structură:

CLINAME Personajul 40

INVDATE Personajul 8

INVAMT Personajul 7

PLATA Caracterul 7

INVBAL Personajul 5

De data aceasta, câmpul „invbal” este dimensionat la 5 caractere, deoarece aceasta este lungimea necesară pentru a stoca prima valoare care este calculată (acum o valoare valutară transformată „0,00 GBP”) și, încă o dată, pierdem datele din orice altă înregistrare în care soldul depășește „9,99 GBP”.

Soluția evidentă este de a oferi formatarea adecvată pentru funcția TRANSFORMO; dar de fapt, într-un SQL, interogarea funcției badilo este opțiunea mai bună din două motive. La fel ca TRANSFORMO, va converti oricare dintre tipurile de date standard în echivalentele lor de caractere. Mai important, vă permite să definiți dimensiunea șirului rezultat și forțează Visual FoxPro să dimensioneze coloana generată în consecință. Deci, dacă rescriem SQL-ul de mai sus, după cum urmează:

*** Utilizați PADL() în loc de transformare pentru a obține rezultatele „corecte”.

SELECT PADL( CL.cliname, 40 ) AS clinam, ;

PADL( IN.invdate, 10 ) AS invdate, ;

PADL( IN.invamt, 10 ) AS invamt, ;

PADL( IN.invpaid, 10 ) AS plată, ;

PADL( invamt - invpaid, 10 ) AS invbal ;

FROM sqlcli CL ;

JOIN sqlinv IN ON IN.clikey = CL.clisid ;

COMANDA PENTRU Cliname ;

INTO CURSOR curCorrect

Obținem un cursor a cărui structură este adecvată sarcinii în mână:

CLINAME Personajul 40

INVDATE Personajul 10

INVAMT Personajul 10

PLATA Caracterul 10

INVBAL Personajul 10

Desigur, există multe alte modalități de a converti datele într-un fișier text. Unul care ne place foarte mult (deși este util doar pentru fișierele care sunt necesare în format SDF) este

pentru a utiliza noua funcție STRTOFILE () împreună cu metoda Da taToClip a obiectului aplicației VFP, după cum urmează:

*** Deschide o masă

USE <tabel>

*** Copiați conținutul în clipboard

cliptext = _VFP.DataToClip()

*** Creați un fișier text

STRTOFILE( cliptext, „<nume fișier de ieșire>”)

Copyright 2000 de către Marcia Akins, Andy Kramek și Rick Schummer Toate drepturile rezervate

Cum să verificați optimizarea interogării dvs. (Exemplu: SQLShow.prg)

Funcția Visual FoxPro sys(3054) permite cel mai apropiat echivalent pe care îl avem la un instrument „showplan” pentru verificarea optimizării unei interogări. Deși este oarecum limitat (de exemplu, singura sa opțiune de afișare este directă către fereastra de ieșire curentă), vă poate oferi o mulțime de informații foarte utile despre modul în care Visual FoxPro vă vede interogările. Cea mai rapidă modalitate de a obține rezultatul SYS(3054) într-o formă utilizabilă este să utilizați set alternate pentru a trimite toate rezultatele ecranului într-un fișier la alegerea dvs., după cum urmează:

SETĂ ALTERNATE LA showplan.txt

ACTIVAȚI ALTERNATĂ

Dacă rulați un program, puteți, de asemenea, să suprimați ieșirea de pe ecran folosind SET CONSOLE OFF (dar acest lucru nu are efect dacă doar executați cod din fereastra de comandă). Când ați terminat, anulați ecoul ieșirii folosind:

SETĂ ALTERNATE OFF

SETĂ ALTERNAT LA

Funcția sys(3054) are două niveluri de afișare determinate de parametrul transmis în apelul funcției. Primul nivel (parametru = 1) arată utilizarea indicilor pe tabele și indică Optimizarea Rushmore pentru fiecare tabel implicat în interogare ca fiind nici unul, parțial sau complet. Următorul program (SQLShow.prg) arată cum funcționează:

**************************************************** ********************

* 	Program. ...: SQLShow.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Ilustrați utilizarea raportării VFP ShowPlan

*** Activați raportarea Showplan

SYS(3O54,1) && returnează de fapt „1” indicând că raportarea de nivel 1 este activată

*** Dezactivați ecranul și ieșirea directă către fișier

OPRIȚI CONSOLA

SETĂ ALTERNATE LA showplan.txt

ACTIVAȚI ALTERNATĂ

*** Avem nevoie de șters ON pentru a vedea rezultatele

lcOldDel = SET('ȘTERS')

SETARE ȘTERGĂ PE

*** Executați interogarea

SELECTAȚI CL.cliname, CO.consname ;

FROM sqlcli CL ;

JOIN sqlcon CO ON CO.clikey = CL.clisid ;

ORDER BY clinam, consname ;

INTO CURSOR ijoin

*** Restabiliți setările

PUNEȚI CONSOLA

SETĂ ALTERNATE OFF

SETĂ ALTERNAT LA

SETĂ ȘTERS &lcOldDel

*** Dezactivați raportarea showplan

SYS (3054,0)

Aceasta produce următoarea ieșire (neformatată) în showplan.txt:

Folosind eticheta index Isdel pentru a optimiza tabelul cl

Nivel de optimizare Rushmore pentru tabelul cl: plin

Folosind eticheta index Isdel pentru a optimiza rushmore table co

Nivel de optimizare Rushmore pentru table co: complet

Al doilea nivel (parametru = 11) arată atât utilizarea indexului pentru tabel, cât și pentru orice îmbinări implicate în interogare. Folosind această opțiune, interogarea de mai sus produce următorul rezultat:

Folosind eticheta index Isdel pentru a optimiza tabelul cl

Nivel de optimizare Rushmore pentru tabelul cl: plin

Folosind eticheta index Isdel pentru a optimiza rushmore table co

Nivel de optimizare Rushmore pentru table co: complet

Alăturarea tabelului cl și a tabelului co folosind eticheta index clickey

Acest lucru ne spune că avem o interogare „complet optimizată”. Ambele tabele au un index pe DELETED() și rulăm cu DELETED = ON (consultați secțiunea următoare pentru mai multe detalii despre rolul șters), astfel încât tabelele individuale sunt ambele optimizabile Rushmore. În plus, există un index existent pe câmpul utilizat în condiția de alăturare. Cu toate acestea, dacă ar fi să adăugăm o condiție de filtru la interogare (de exemplu: WHERE consname = "A" AND confname = "B" ), rezultatele ar arăta acum astfel:

Folosind eticheta index Isdel pentru a optimiza tabelul cl

Nivel de optimizare Rushmore pentru tabelul cl: plin

Utilizarea etichetei de index Consname pentru a optimiza rushmore table co

Folosind eticheta index Isdel pentru a optimiza rushmore table co

Nivel de optimizare Rushmore pentru tabelul co: parțial

Unirea tabelului co și a tabelului cl folosind eticheta index Clisid

Observați că tabela „co” este acum doar parțial optimizată deoarece, deși există un index pe „consname” care poate fi folosit pentru prima parte a condiției de filtru, nu există un index corespunzător care să poată fi utilizat pentru a doua.

Lucrurile devin puțin mai complexe atunci când sunt implicate mai mult de două mese, dar informațiile sunt încă foarte revelatoare. Luați în considerare următoarea interogare (rezultatele reale nu contează pentru moment):

SELECT CL.cliname, CO.consname, PH.phnnum, Sl.Invdate ;

FROM sqlcli CL ;

JOIN sqlcon CO ON CO.clikey = CL.clisid;

JOIN sqlpho PH ON PH.conkey = CO.consid;

JOIN sqlinv SI ON SI.clikey = CL.clisid ;

ORDER BY clinam, consname ;

INTO CURSOR ijoin

Când aceasta este executată, showplan ne oferă următorul raport:

Folosind eticheta index Isdel pentru a optimiza tabelul cl

Nivel de optimizare Rushmore pentru tabelul cl: plin

Folosind eticheta index Isdel pentru a optimiza rushmore table co

Nivel de optimizare Rushmore pentru table co: complet

Folosind eticheta index Isdel pentru a optimiza rushmore tabelul ph

Nivel de optimizare Rushmore pentru ph tabel: plin

Folosind eticheta index Isdel pentru a optimiza tabelul si

Nivel de optimizare Rushmore pentru tabelul si: plin

Unirea tabelului cl și a tabelului si folosind eticheta de index Clikey

Unirea rezultatului intermediar și a tabelului co folosind eticheta de index Clikey

Unirea rezultatului intermediar și a ph-ului tabelului folosind eticheta de index Conkey

Primele câteva rânduri sunt similare cu ceea ce am văzut deja, dar sunt informațiile de unire care ne interesează cu adevărat. Acum putem vedea secvența pe care Visual FoxPro o folosește de fapt pentru a se alătura tabelelor. În acest caz, mai întâi unește „SI (facturi) cu „CL” (clienți) și apoi adaugă „CO” (contacte) și în final „PH (numere de telefon). În mod normal, puteți permite în siguranță Visual FoxPro să stabilească cel mai bun mod de a se alătura tabelelor, dar ocazional va greși (sau cel puțin, le puteți alătura într-un mod care nu vă oferă rezultatele pe care le-ați dorit). În aceste situații, putem folosi cuvântul cheie suplimentar „FORCE” din clauza FROM pentru a ne asigura că Visual FoxPro rulează interogarea exact așa cum am definit-o. De exemplu, modificarea exemplului de interogare pentru a forța secvența de unire:

SELECT CL.cliname, CO.consname, PH.phnnum, SI.Invdate ;

FROM FORCE sqlcli CL ;

JOIN sqlcon CO ON CO.clikey = CL.clisid;

JOIN sqlpho PH ON PH.conkey = CO.consid;

JOIN sqlinv SI ON SI.clikey = CL.clisid ;

ORDER BY clinam, consname ;

INTO CURSOR ijoin

produce următoarele rezultate din showplan și confirmă că Visual FoxPro a făcut într-adevăr ceea ce am cerut:

Folosind eticheta index Isdel pentru a optimiza tabelul cl

Nivel de optimizare Rushmore pentru tabelul cl: plin

Folosind eticheta index Isdel pentru a optimiza rushmore table co

Nivel de optimizare Rushmore pentru table co: complet

Unirea tabelului cl și a tabelului co folosind eticheta de index Clikey

Nivel de optimizare Rushmore pentru rezultat intermediar: niciunul

Folosind eticheta index Isdel pentru a optimiza rushmore tabelul ph

Nivel de optimizare Rushmore pentru ph tabel: plin

Unirea rezultatului intermediar și a ph-ului tabelului folosind eticheta de index Conkey

Nivel de optimizare Rushmore pentru rezultat intermediar: niciunul

Folosind eticheta index Isdel pentru a optimiza tabelul si

Nivel de optimizare Rushmore pentru tabelul si: plin

Unirea rezultatului intermediar și a tabelului folosind eticheta de index Clikey

Deci, când ar trebui să folosim de fapt showplan? Răspunsul simplist este, desigur, întotdeauna! Cu toate acestea, în practică, ar trebui să fie primul lucru pe care îl verificați în două situații:

• 	Când vă întrebați de ce o interogare durează mai mult decât se aștepta

• 	Când o interogare returnează rezultate neașteptate

Efectul DELETED() asupra SQL

Acesta este poate unul dintre cele mai puțin înțelese aspecte ale motorului SQL Visual FoxPro. În timp ce detaliile despre modul în care funcționează efectiv optimizarea Rushmore sunt încă un secret bine păzit, faptul esențial este că Rushmore se bazează pe indici pentru a accelera selecția datelor. Cel mai important factor este modul în care gestionează înregistrările marcate pentru ștergere.

Când rulați Visual FoxPro cu deleted setat la pornit, îi spuneți să ignore orice înregistrare care este marcată pentru ștergere, dar cum se poate afla ce înregistrări sunt marcate pentru ștergere? Răspunsul este că, cu excepția cazului în care aveți un index care include în mod specific acele înregistrări, acesta trebuie să verifice fiecare înregistrare individual - chiar dacă nu aveți înregistrări marcate pentru ștergere. Aceasta este o operațiune relativ lentă și este probabil cea mai comună cauză a performanței slabe SQL în aplicații. Soluția este simplă, includeți un index specific pe DELETED() .

Rularea cu deleted set off evită necesitatea unui index pentru deletedo, dar înseamnă că poate fi necesar să includeți în mod explicit un filtru suplimentar în interogări (de ex. WHERE ! DELETED() ) dacă tabelele pot conține înregistrări șterse. Cu toate acestea, acest lucru va avea ca rezultat doar optimizarea „parțială” a interogărilor și vă poate oferi o performanță mai slabă decât utilizarea unui index pe ștergere și setarea deleted = on, chiar dacă nu aveți niciodată înregistrări șterse.

Cu toate acestea, crearea unui index pe ștergere nu este, în sine, panaceul universal - mai ales atunci când sunt implicate tabele mari. Acest lucru se datorează faptului că ori de câte ori accesați un tabel, (fie cu o comandă USE explicită, fie printr-o interogare) Visual FoxPro caută și încarcă în memorie indexul de pe deletedo . Dacă rulați într-o rețea, aceasta poate fi o sarcină lungă pentru tabele foarte mari și, în astfel de circumstanțe, este de obicei mai bine să nu aveți un index pe deletedo . Din păcate, nu există reguli stricte și rapide în acest sens și singurul sfat real pe care îl putem oferi este să încercați lucrurile în propriul mediu pentru a determina combinația optimă de indici și setarea ștergerilor.

Deci ce indici ar trebui să creez?

Din păcate, nu există răspunsuri „ușoare” la această întrebare. După cum ați realizat din secțiunile precedente, rolul indicilor pe tabele este crucial atunci când luăm în considerare SQL în Visual FoxPro. Deși este imposibil să fii absolut prescriptiv în acest sens, există câteva linii directoare de bază, dar fii pregătit să le modifici ca urmare a testării lucrurilor cu propriile date în propriul mediu operațional.

Prima este că ar trebui să creați întotdeauna un index pe câmpul cheie primară al tabelelor - chiar dacă acesta nu este definit ca o „cheie primară” în baza de date. Dacă nu utilizați deja chei surogat (și de ce nu?), ar trebui să creați totuși un index pe orice câmp sau combinații de câmpuri care identifică în mod unic o înregistrare. Dacă nimic altceva, veți avea nevoie de acest lucru pentru a vă putea alătura tabelului eficient în interogări.

În al doilea rând, luați în considerare crearea unui index pentru șters». Deși acest lucru va accelera fără îndoială interogările atunci când rulați Visual FoxPro cu DELETED = ON, poate avea un impact nedorit asupra performanței în alte domenii (de exemplu, încărcarea formularelor), mai ales dacă tabelele sunt foarte mari. Ca întotdeauna, testați în propriul mediu.

În al treilea rând, creați indecși pentru orice câmpuri pe care în mod normal veți efectua căutări sau veți seta filtre. Acest lucru va permite lui Rushmore să optimizeze atât îmbinările tabelelor, cât și condițiile de filtrare în mod corespunzător și va îmbunătăți considerabil performanța interogărilor dvs. Amintiți-vă că expresia index ar trebui să se potrivească exact cu cea pe care o veți utiliza pentru a specifica condiția de căutare sau de filtrare. Deci, dacă adăugați un index pe „nume”, dar în mod normal veți filtra pentru „ UPPER (nume), ” atunci creați indexul pe

SUS (nume) ", de asemenea.

Prezența indecșilor ale căror chei nu sunt definite în exact aceiași termeni care sunt utilizați la interogarea tabelelor este probabil a doua cea mai frecventă cauză a performanței slabe în SQL, dar este una care este ușor de detectat folosind showplan. Veți ști că ați greșit acest lucru atunci când vedeți un rezultat care arată optimizarea parțială pentru o interogare care ar trebui să returneze optimizarea completă, deoarece știți că există un index pe câmpul în cauză.

În al patrulea rând, evitați crearea de indici condiționali (adică cei care folosesc „for <cond±tion>”) sau indici bazați pe inegalitate (adică cei care folosesc NOT <condition> ). Rushmore nu poate folosi indici de niciun fel și pur și simplu îi ignoră. Dacă aveți nevoie de ele din alte motive, atunci creați atât indexul necesar, cât și un index simplu pe câmp. (De asemenea, acesta este ușor de detectat folosind showplan.)

În cele din urmă, evitați să vă inversați mesele. Reacția ta inițială la această întrebare ar putea fi că cel mai sigur ar fi să creezi pur și simplu un index pe fiecare câmp din tabel - la urma urmei, nu știi niciodată pe ce ai putea dori să cauți, nu? Aceasta este, totuși, de obicei o mișcare proastă, mai ales în tabelele care au niveluri ridicate de activitate (fie inserări, actualizări sau ștergeri), deoarece forțați Visual FoxPro să mențină un număr mare de indici cu fiecare tranzacție de pe masă. Acest lucru poate afecta semnificativ performanța și, ca întotdeauna, există un compromis între performanța într-un domeniu și performanța într-un altul.
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Care este mai bine pentru actualizarea tabelelor, comenzilor SQL sau native FoxPro?

Aceasta este o întrebare complexă, iar răspunsul depinde de tipul de actualizare și de natura tabelului. Cea mai bună soluție variază și în funcție de dacă adăugați înregistrări noi sau actualizați datele existente.

SQL INSERT vs APPEND

În general, SQL INSERT va oferi performanțe mai bune, deoarece necesită doar o singură actualizare a oricăror indici asociați cu tabelul. Când adăugați înregistrări într-un tabel, Visual FoxPro trebuie să actualizeze antetul tabelului și să actualizeze orice index cu valori noi în funcție de ceea ce a fost adăugat. Utilizarea insertului este mai eficientă deoarece necesită o singură operație. Noua înregistrare și valorile sale sunt adăugate simultan și indicii actualizați.

Cu toate acestea, pentru a realiza acest lucru trebuie să aveți la dispoziție toate informațiile atunci când se efectuează inserarea și acest lucru nu este întotdeauna posibil (de exemplu, atunci când adăugați înregistrări goale printr-un formular de introducere a datelor). În această situație, mai ales dacă tabelele sunt în buffer, nu are nicio diferență practică în modul în care adăugați înregistrarea.

SQL UPDATE/DELETE vs REPLACE/DELETE

Răspunsul aici depinde de câte înregistrări trebuie actualizate. Pentru actualizările unei singure înregistrări, în special în cazul în care înregistrarea este deja selectată și disponibilă imediat, am avea tendința de a rămâne cu comenzile ÎNLOCUIRE/ȘTERGERE. De fapt, chiar și atunci când înregistrarea necesară nu este disponibilă imediat, de obicei este mai bine să folosiți o strategie de căutare și înlocuire/ștergere, mai degrabă decât echivalentul SQL. Motivul este pur și simplu că comenzile SQL necesită o clauză where și trebuie să verifice întregul tabel (sau cel puțin indecșii) pentru a se asigura că nu este specificată mai mult de o înregistrare. Dimpotrivă, domeniul implicit pentru comenzile native Visual FoxPro este întotdeauna înregistrarea curentă (adică următoarea 1) și astfel, pentru actualizări sau ștergeri de înregistrări individuale, este de obicei mai rapidă.

Când trebuie să actualizăm mai multe înregistrări, situația este diferită. Atât înlocuirea cât și ștergerea pot avea un domeniu de aplicare condiționat (adică FOR <condition> ). Acest lucru îi plasează în aceeași categorie ca și comenzile SQL, cu clauza unde și se vor aplica aceleași reguli. Cu condiția ca condiția să fie optimizabilă, Visual FoxPro va folosi Rushmore în ambele situații, iar diferența va fi nesemnificativă. Cu toate acestea, atunci când condiția nu este optimizabilă, comenzile SQL vor oferi de obicei o performanță puțin mai bună. Răspunsul, ca întotdeauna, este de a testa cazurile individuale și de a decide asupra meritelor lor.
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Concluzie

Întreaga problemă a utilizării SQL în Visual FoxPro, indiferent dacă este direct sau în vizualizări, depinde de atât de mulți factori încât este foarte dificil să fii prescriptiv cu privire la orice aspect al acestuia. Regula de aur este să vă planificați în mod corespunzător structurile și indecșii tabelelor și să testați, testați și retestați soluțiile în cât mai multe moduri diferite. Utilizați sys(3054) pentru a confirma că ceea ce vă așteptați este ceea ce se întâmplă cu adevărat și fiți pregătiți pentru câteva surprize atunci când o faceți.
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Capitolul 10 - Clase non-vizuale

„Încântarea că am înțeles un sistem foarte abstract și obscur îi determină pe majoritatea oamenilor să respecte adevărul a ceea ce demonstrează.” (Aforisme „Caiet J” de GC Lichtenberg)

Abilitatea de a ne defini propriile clase în Visual FoxPro este una dintre cele mai puternice caracteristici ale limbajului. Ne permite să creăm instrumente care pot fi reutilizate într-o mare varietate de circumstanțe și, deoarece sunt create ca clase, ne permite, de asemenea, să extindem sau să modificăm comportamentele lor standard atunci când cerințele se schimbă în aplicații specifice. Faptul că putem crea și clase în cod deschide un domeniu complet nou de posibilități pentru dezvoltarea abordărilor standard ale problemelor comune. În acest capitol explorăm câteva dintre clasele non-vizuale pe care le-am dezvoltat pentru a ne ușura viața atunci când scriem aplicații Visual FoxPro. Deși nu sunt concepute special ca clase „cadru”, o mare parte din funcționalitatea descrisă în aceste clase ar intra de obicei în domeniul de aplicare al unui cadru de aplicație.
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Cum pot folosi fișierele INI? (Exemplu: inimaint.scx)

Deși există o tendință din ce în ce mai mare de a utiliza Registrul Windows pentru stocarea datelor care se referă la o aplicație, fișierul INI mai vechi oferă în continuare câteva avantaje pentru dezvoltatorul aplicației. În primul rând, este pur și simplu un fișier text care poate fi stocat local pe o mașină client pentru a păstra informații specifice utilizatorului. Acesta este un beneficiu major deoarece îl face ușor de manipulat - indiferent dacă faceți acest lucru în mod programatic sau cu orice editor de text disponibil. În al doilea rând, deoarece poate fi localizat în directorul de pornire al unei aplicații, este ușor de eliminat dacă aplicația trebuie să fie eliminată de pe o mașină și este ușor de înlocuit dacă este ștearsă din neatenție. În al treilea rând, este posibil să instruiți chiar și un utilizator începător cum să corecteze erorile sau să adăugați elemente noi la un fișier INI dacă este necesar - chiar și prin telefon, dacă este necesar.

În timp ce registrul oferă o casă bună pentru informațiile care sunt necesare „la nivelul întregului sistem”, deoarece sunt disponibile automat pentru aplicațiile Windows, nu este nici dezvoltator, nici ușor de utilizat. Este dificil, ca să nu spunem periculos, să manipulați programatic și dezinstalarea completă a unei aplicații este mult mai dificilă atunci când intrările trebuie să fie localizate și șterse din registru. În plus, am fi foarte nervoși să oferim unui utilizator cu experiență (dară să nu mai vorbim unui novice) acces la registrul mașinii sale - și perspectiva de a instrui un utilizator, prin telefon, să editeze registrul este una care, sincer, ni se pare terifiantă! În cele din urmă, dacă informațiile care urmează să fie stocate sunt strict specifice aplicației și nu sunt accesate de nimic, cu excepția aplicației, nu vedem niciun motiv pentru a nu le stoca împreună cu aplicația.
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Prezentare generală

Managerul de fișiere INI este o clasă care este concepută pentru a oferi o gestionare fără probleme a fișierelor .INI (sau a oricărui alt fișier bazat pe text care respectă formatul de fișier INI). Un fișier INI este un fișier text structurat ("STF") care constă dintr-o serie de titluri de secțiune (trebuie să existe întotdeauna cel puțin unul dintre acestea) delimitate cu „[]” și apoi perechi Element și valoare care includ un „=" . Toate datele sunt păstrate ca șiruri de caractere în fișierele INI și, deși există o limitare de 64k la dimensiunea unui fișier INI, este puțin probabil ca majoritatea aplicațiilor să se apropie de aceasta. Un fișier tipic ar putea arăta cam așa:

Nume: SYSTEM.INI

[SISTEM]

NAME=SomeSystem

COPYRIGHT=Tightline Computers Ltd

[CONSTANTE]

STANDARDRATE=17,50

RATA CONCESIUNE=15,00

UTILITYRATATE=8,50

Scopul cheie al unui fișier INI este de a oferi un mijloc de stocare a informațiilor solicitate de o aplicație fără a fi nevoie să recurgă la utilizarea unui tabel de date. Deoarece un fișier INI este un fișier text simplu, informațiile din acesta pot fi actualizate sau modificate de către un utilizator final folosind orice editor de text.

Windows oferă o serie de funcții API care pot accesa și scrie în fișiere INI, dar, ca toate aceste funcții, sunt relativ complexe. Managerul este un exemplu de „Clasă Wrapper” care oferă funcții de gestionare de bază pentru fișierele INI, oferind în același timp o interfață mai prietenoasă pentru dezvoltatori pentru aceste funcții API.

Managerul de fișiere INI expune șase metode în interfața sa publică, care sunt descrise în detaliu mai jos. Este conceput pentru a fi instanțiat ca obiect la nivel de sistem - deși poate fi creat ca obiect tranzitoriu dacă este necesar sau ca componentă a unui „Obiect de aplicație”. Aproape toate funcționalitățile din Managerul de fișiere INI sunt interne, excepțiile fiind că necesită unele funcții Visual FoxPro care, înainte de versiunea 6.0, erau disponibile doar în biblioteca FoxTools. Dacă această clasă urmează să fie utilizată cu o versiune anterioară a Visual FoxPro, va fi necesară o modificare a metodei " ChkFileName()" pentru a încărca biblioteca dacă aceasta nu este deja prezentă în memorie.
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Inițializarea managerului

Există două moduri de a crea obiectul manager. Puteți fie să încărcați definiția clasei ca fișier de procedură (care ar fi cea mai bună abordare dacă managerul va fi creat ca obiect tranzitoriu), fie puteți rula programul direct și creați managerul ca obiect global. (Acest lucru va crea referința la manager ca o variabilă PUBLIC, dar nu va încărca fișierul în memorie ca procedură.)

Indiferent de modalitatea folosită, procesul de inițializare ia un parametru opțional care este numele fișierului INI care va fi folosit ca fișier implicit de către manager. Procesele de verificare internă vor formata acest nume într-un nume de fișier complet calificat cu extensia implicită „INI” și calea implicită a unității și directorului curent. Cu toate acestea, anumite căi sau alte extensii vor fi respectate dacă sunt furnizate.

Tabelul 10.1 Crearea obiectului manager de fișiere INI

Crearea Managerului ca obiect global 	Crearea Managerului ca obiect tranzitoriu
RELEASE goIniMgr 	DO iniproc CU <inifile>
LANSAREA PUBLICĂ goIniMgr goIniMgr	
SETĂ PROCEDURA LA ADITIVUL iniproc	
GoIniMgr = CREATEOBJECT('iniproc', <inifile>)	

Dacă fișierul trecut ca fișier implicit nu poate fi localizat pe calea specificată sau pe calea implicită, va fi creat cu o singură secțiune care poartă numele fișierului. Astfel, comanda de configurare: goIniMgr = CREATEOBJECT('iimgr', 'c:\testing\nosuch.txt')

va avea ca rezultat (având în vedere permisiunile corespunzătoare și drepturile de creare a fișierelor) crearea unui fișier numit „NOSUCH.TXT în directorul „C:\TESTING” care conține pur și simplu antetul de secțiune „[NOSUCH]”, deoarece, așa cum sa menționat în introducere, un fișier INI necesită întotdeauna cel puțin o secțiune antet.

Opțiunea nocreate

Clasa poate accepta un al doilea parametru, logic, care este utilizat pentru a determina dacă un fișier INI nou ar trebui creat dacă nu este găsit un fișier specificat. Setarea, inițializată la pornire, este păstrată într-o proprietate protejată și atunci când este setată în mod explicit la .t., împiedică Managerul de fișiere INI să încerce să creeze un fișier atunci când fișierul solicitat nu este găsit. Prin urmare:

goIniMgr = CREATEOBJECT( 'inimgr', 'c:\testing\nosuch.txt', .t.)

va instanția în continuare obiectul manager și va seta proprietatea implicită a fișierului, dar nu va crea fișierul solicitat dacă nu există deja.
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Fișierul implicit

Managerul INI menține o colecție internă de nume de fișiere pe care le recunoaște și, de asemenea, păstrează unul dintre aceste fișiere înregistrat ca fișier implicit . Când este apelată orice metodă de citire sau scriere, datele vor fi citite sau scrise în fișierul implicit, cu excepția cazului în care un anumit fișier este transmis ca parte a instrucțiunii. Scopul fișierului implicit este pur și simplu acela de a evita necesitatea de a trece și valida în continuare numele fișierului aceluiași fișier INI, deoarece, în mod normal, aplicațiile vor folosi doar un singur fișier INI.

Cu toate acestea, Managerul INI are capacitatea de a interoga un anumit fișier fără a modifica de fapt setarea implicită (de exemplu, pentru a citi o anumită valoare dintr-un fișier System INI sau STF) și de a schimba orice fișier este înregistrat ca implicit în orice moment.
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Înregistrarea fișierului

Managerul INI utilizează o procedură de înregistrare internă pentru a se asigura că toate numele de fișiere transmise acestuia sunt calificate corespunzător cu calea și extensia completă. Dacă nu este trecută nicio cale, se presupune că unitatea curentă de lucru și directorul sunt luate în considerare, iar dacă nu este inclusă nicio extensie, fișierul se presupune că are o extensie „.ini”. Deși valorile implicite sunt atribuite pentru a înlocui elementele lipsă de date, managerul INI va respecta orice cale sau informații despre extensie care îi sunt transmise.
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Interfața publică

Interfața publică INI Manager este extrem de simplă. Există doar șase metode care pot fi accesate și managerul nu are deloc proprietăți expuse. Metodele individuale și exemplele despre cum pot fi utilizate sunt discutate în secțiunile următoare.

GetIniFile()

Metoda GetIniFile() nu acceptă parametri și pur și simplu returnează numele oricărui fișier pe care Managerul INI îl definește în prezent ca fișier implicit. Dacă nu este înregistrat niciun fișier, GetIniFile() returnează un șir de caractere gol.

Exemple:

Această metodă poate fi apelată ca parte a unui test pentru a se asigura că un fișier este înregistrat:

IF EMPTY( goIniMgr.GetIniFile() )

*** Nu este definit niciun fișier INI

ENDIF

Alternativ, numele de fișier complet calificat al fișierului implicit curent poate fi preluat într-o variabilă,

sau valoarea returnată poate fi utilizată într-o instrucțiune de înlocuire sau actualizare. Următoarea comandă afișează pur și simplu numele fișierului INI înregistrat în prezent pe ecran:

? goIniMgr.GetIniFile()

SetIniFile()

Metoda SetIniFile() este utilizată pentru a seta un anumit fișier INI ca țintă implicită pentru operațiunile de citire/scriere sau pentru a crea un fișier INI nou și pentru a-l seta ca implicit pentru utilizare ulterioară. Metoda ia un singur parametru - numele unui fișier - și setează acel fișier ca noul Fișier implicit pentru utilizare de către obiectul Manager. Valoarea returnată este numerică și va avea una dintre cele trei valori posibile:

• 	-1 Eroare în parametrii de intrare

• 	0 Nu se poate înregistra fișierul

• 	1 Fișier specificat este setat ca implicit

Dacă fișierul al cărui nume este furnizat nu există pe calea specificată (sau implicită), Managerul INI va crea fișierul și îi va atribui o singură secțiune numită același cu numele fișierului și va face din noul fișier fișierul implicit.

Exemple:

Pentru a seta fișierul standard Windows „WIN.INI” ca fișier implicit:

lnSuccess = goIniMgr.SetIniFile('C:\WINDOWS\WIN.INI')

Pentru a seta un fișier INI în directorul de lucru curent ca fișier implicit:

InSuccess = goIniMgr.SetIniFile('eusys')

Pentru a crea un fișier nou folosind formatul de fișier INI într-o anumită locație și pentru a-l seta ca implicit:

InSuccess = goIniMgr.SetIniFile('G:\DEV\SYSTEM\WORK.STF')

GetValue( <Secțiune>, <Element> [,<fișier>] )

Metoda GetValue() returnează valoarea stocată pentru un articol specificat din secțiunea specificată a unui fișier care respectă formatul standard de fișier INI. Metoda ia doi parametri obligatorii (numele Secțiunii și numele articolului) și un al treilea opțional (fișierul de utilizat). Dacă al treilea parametru este omis, se presupune fișierul implicit curent.

Valoarea returnată va fi întotdeauna de tipul caracter și va fi fie valoarea specificată, fie un șir gol. Această metodă nu returnează o valoare de eroare în niciun caz. Astfel, dacă fie Secțiunea, fie numele articolului nu există, sau dacă combinația de Secțiune și Articol este invalidă, un șir gol este tot ce este returnat. În mod similar, dacă un parametru este omis sau invalid, este returnat un șir gol.

Exemple:

Pentru a prelua valoarea din fișierul implicit curent al elementului „Nume” din secțiunea „Sistem”:

lcName = goIniMgr.GetValue( 'SISTEM', 'NUME' )

Pentru a prelua numele driverului ODBC configurat pentru citirea tabelelor FoxPro în clipboard:

_ClipText = goinimgr.getvalue('FIȘIERE FOXPRO', 'DRIVER32', 'c:\windows\odbc.ini' )

Notă: Preluarea unei valori dintr-un fișier altul decât fișierul implicit nu modifică setarea implicită a fișierului. Singura modalitate de a schimba setarea implicită a fișierului este prin metoda SetIniFile().

SetValue( <Secțiune>, <Articol>, <Valoare> [,<fișier>] )

Metoda SetValue() scrie valoarea specificată în elementul și secțiunea specificate. Dacă fie Secțiunea, fie Elementul nu există deja în fișierul specificat, intrările corespunzătoare sunt create, altfel valorile existente sunt pur și simplu suprascrise. Toți parametrii, inclusiv valoarea, trebuie să fie transmiși ca șiruri de caractere, dar parametrii nu țin cont de majuscule și minuscule. Se aplică regulile obișnuite care guvernează șirurile de caractere, iar funcțiile de conversie FoxPro pot fi încorporate în apelul de metodă în mod normal.

SetValue() returnează o valoare numerică ca una dintre:

• 	-1 Eroare în parametrii de intrare

• 	0 Nu se poate scrie în fișierul specificat

• 	1 valoare scrisă cu succes

Exemple:

Pentru a seta valoarea elementului DATE în secțiunea Sistem a fișierului implicit:

lnSuccess = goIniMgr.SetValue( 'SISTEM', 'DATA', DMY(DATA()) )

Pentru a crea un articol nou în secțiunea de sistem a fișierului implicit:

InSuccess = goIniMgr.SetValue( 'SISTEM', 'element nou', 'valoare nouă' )

Pentru a crea o secțiune și un articol nou în fișierul implicit:

IF goIniMgr.SetValue( 'NewSection', 'NewItem', 'somevalue' ) > 0

*** Intrări scrise cu succes

ENDIF

Notă: SetValue() NU va crea un fișier nou dacă fișierul specificat nu există deja sau dacă nu există niciun fișier implicit înregistrat. În aceste situații, valoarea returnată va fi întotdeauna 0.

ReadIniFile( <@ArrayName> [,<fișier>] )

Metoda ReadIniFile() citește un întreg fișier INI într-o matrice cu două coloane (care trebuie creată în rutina de apelare și transmisă prin referință). Matricea va fi întotdeauna dimensionată corect pentru valorile care se găsesc în fișierul INI. Prima coloană a matricei conține numele titlurilor de secțiuni (inclusiv delimitatorii lor „[]”) sau Articole, în timp ce a doua coloană conține simbolurile de delimitare „[]” pentru titlurile de secțiuni sau valorile reale pentru Articole.

ReadIniFile() returnează o valoare numerică care indică numărul de linii valide care au fost citite în matricea țintă. Dacă nu este transmis niciun nume de fișier ca parametru, se presupune fișierul implicit.

Exemplu:

Pentru a citi întregul conținut al fișierului implicit în matricea laData:

LOCAL ARRAY laData[1]

DACĂ goIniMgr.ReadIniFile( @laData ) > 0

*** Cel puțin un rând găsit

ALTE

*** Nu au fost returnate date

ENDIF

Conținutul laData va arăta cam așa:

laData[1,1]

laData[1,2] laData [2,1] laData[2,2] laData[3,1] laData[3,2]

[SISTEM]

[]

NUME

Sistem de testare

DATA

01/10/1998

WriteIniFile( <@ArrayName> [,<fișier>] )

Metoda WriteIniFile() scrie conținutul unui tablou cu două coloane (care trebuie creat în rutina de apelare și transmis prin referință) în fișierul INI specificat. Prima coloană a matricei trebuie

conțin numele titlurilor de secțiune (nu trebuie să se folosească „[J delimitatorii ar trebui să fie utilizați”) sau articolelor, în timp ce a doua coloană trebuie să conțină simbolurile de delimitare „[]” pentru anteturile de secțiuni și valorile reale pentru articole.

Matricea trebuie să fie ordonată astfel încât primul Element să fie întotdeauna un nume de Secțiune (adică are al doilea element setat la „[]”). Rândurile ulterioare ale matricei sunt tratate ca perechi Element/Valoare care aparțin acelei secțiuni până când este întâlnit un nou rând Section Header.

Dacă nu este găsit un nume de secțiune, o nouă secțiune este creată automat în fișierul INI, iar dacă nu este găsit un nume de articol, articolul va fi adăugat la secțiunea părinte.

WriteIniFile() returnează o valoare numerică care indică numărul de linii valide care au fost scrise în fișierul țintă. Dacă nu este transmis niciun nume de fișier ca parametru, se presupune fișierul implicit, iar dacă fișierul specificat nu poate fi găsit sau scris, este returnată o valoare 0.

Exemplu:

Pentru a scrie un fișier INI dintr-o matrice:

LOCAL ARRAY laData[4,2]

laData[1,1] = „SISTEM”

laData[1,2] = „[]”

laData[2,1] = „NUME”

laData[2,2] = „Sistem de testare”

laData[3,1] = „NewSection”

laData[3,2] = „[]”

laData[4,1] = „Versiune”

laData[4,2] = "1.0G"

DACĂ goIniMgr.WriteIniFile( @laData ) > 0

*** Datele au fost scrise cu succes

ENDIF

Fișierul INI va arăta astfel:

[SISTEM]

NAME=Sistem de testare

[SECȚIUNEA DE ȘTIRI]

Versiune=1.0G
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Folosind managerul de fișiere INI

Cea mai evidentă utilizare a managerului de fișiere INI este pentru preluarea și actualizarea constantelor de sistem, stocate într-un fișier text extern din interiorul unei aplicații. Întreaga structură a managerului este concepută special pentru a simplifica acest proces într-un mediu de aplicație tipic în care un singur fișier INI este utilizat pentru a stoca toate datele relevante, făcând acel fișier ca implicit pentru toate operațiunile. Cu toate acestea, atât metodele GetValueO, cât și SetValue() oferă capacitatea de a adresa fișiere altele decât fișierul implicit, atunci când este necesar.

A doua utilizare principală a managerului de fișiere INI este de a ajuta la întreținerea fișierelor INI ale aplicației. Metodele ReadIniFile() și WritelniFileQ sunt concepute pentru a transfera un bloc de informații între o matrice FoxPro și un fișier INI. Probabil cel mai simplu mod de a gestiona acest lucru este de a crea un tabel (sau cursor) cu două coloane care corespund structurii matricei necesare și de a utiliza SQL SELECT... INTO ARRAY și SQL INSERT INTO .... FROM ARRAY de la FoxPro pentru a obține date. în ceva care poate fi folosit într-o formă. Exemplul de cod care însoțește acest capitol include un formular ("INIMAINTSCX") care folosește un cursor pentru a menține intrările pentru un fișier INI.

Figura 10.1 Formular simplu de întreținere pentru fișierele INI

Deși nu este deloc cuprinzător în gestionarea erorilor, acest exemplu arată cum să utilizați Managerul de fișiere INI pentru a citi și scrie un fișier INI. Formularul prevede citirea fie dintr-un fișier INI existent, crearea unuia complet nou, fie citirea datelor dintr-un tabel Visual FoxPro. În acest exemplu, managerul este creat ca obiect global (goIniMgr) în metoda Load a formularului.

Citirea datelor din sursa specificată în cursorul formularului este gestionată de metoda personalizată ReadFile() după cum urmează:

LOCAL ARRAY laTfer[l,2]

LOCAL IcSceFile, IcOldFile

CU ThisForm

*** Verificați fișierul sursă, ștergeți cursorul dacă este creat un fișier nou

DACĂ .chkSource() > 0

DACĂ EMPTY ( ALLTRIM ( .txtFName.Value ) )

*** Crearea unui fișier nou - doar returnați ZAP ÎN curIniFile

. RefreshForm ( )

ÎNTOARCERE

ENDIF

ALTE

*** Verificarea fișierului sursă a eșuat!

ÎNTOARCERE

ENDIF

*** Sursa specificată este OK, așa că adunați calea completă și numele fișierului

lcSceFile = ALLTRIM( ADDBS( .txtDir.Value )) + ALLTRIM( .txtFName.Value ) IF JUSTEXT( lcSceFile ) = „DBF”

*** Este un tabel, așa că citește-l într-o matrice

SELECTează antetul, elementul din (lcSceFile) ORDER BY sortator INTO ARRAY laTfer ELSE

*** Este un fișier INI (poate). Așa că citește

goIniMgr.ReadIniFile( @laTfer, lcSceFile )

ENDIF

*** Ștergeți cursorul și Copierea rezultate în

ZAP ÎN curIniFile

INSERT INTO curIniFile FROM ARRAY laTfer

*** Eliminați titlul „[]” - oricum vor fi rescrise

ÎNLOCUIȚI TOATE titlurile CU CHRTRAN( titlu, '[]','') ÎN curIniFile .RefreshForm()

SE TERMINA CU

Scrierea datelor din cursor este gestionată în metoda personalizată WriteFile() după cum urmează:

LOCAL ARRAY laTfer[1,2]

LOCAL lcOldFile, lcDestFile

CU ThisForm

*** Trebuie să aibă o destinație

DACĂ EMPTY( .txtDestFName.Value )

MESSAGEBOX( „Trebuie specificat un fișier de ieșire!”, 16, „Nu se poate continua”)

.txtDestFName.SetFocus()

ÎNTOARCERE

ENDIF

*** Avem o destinație

lcDestFile = ALLTRIM(ADDBS(.txtDestDir.Value)) + ALLTRIM(.txtDestFName.Value)

*** Ștergeți fișierul dacă acesta există deja

DACĂ ! FILE( lcDestFile )

ȘTERGE FIȘIER (lcDestFile)

ENDIF

*** Acum creați un fișier nou, gol, gata de scris

*** Trebuie să facem acest lucru pentru a ne asigura că ștergerile sunt făcute corect

lnHnd = FCREATE( lcDestFile )

IF lnHnd < 0 MESSAGEBOX( 'Nu se poate crea un fișier nou ' + CHR(13) ;

+ lcDestFile, 16, „Nu se poate continua”)

ÎNTOARCERE

ALTE

FCLOSE(lnHnd)

ENDIF

*** Acum scrieți noul fișier - ignorați câmpurile goale de „titlu”.

SELECTAȚI * FROM curinifile WHERE ! EMPTY(heading) INTO ARRAY laTfer

CU golniMgr

*** Scrieți conținutul fișierului

.WriteIniFile( @laTfer, lcDestFile )

SE TERMINA CU

*** Ștergeți cursorul

ZAP ÎN curIniFile

.RefreshForm()

SE TERMINA CU
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Cum să selectați o zonă de lucru diferită, stil OOP! (Exemplu:

ChgArea.prg)

Unul dintre cele mai des scrise fragmente de cod, în aproape orice aplicație, arată cam așa:

*** Salvați zona de lucru curentă

lnSelect = SELECT ()

*** Selectați Zona necesară

DACĂ ! FOLOSIT( <Alias> )

USE <tabel> ÎN 0 DIN NOU ALIAS <Alias>

ENDIF

SELECTAȚI <Zona nouă de lucru>

*** Fă ceva acolo

<comandă>

*** Reveniți la zona de lucru inițială

SELECTARE (lnSelect)

Acum, desigur, acest lucru nu este chiar foarte dificil, dar ea sau o variantă se repetă de multe ori într-o aplicație. Chiar ar trebui să putem face mai bine decât asta acum că avem toată puterea Orientării obiectelor în spate și într-adevăr putem.

Prezentare generală

Clasa SelAlias este proiectată să accepte numele alias al unui tabel ca parametru și să comute la zona de lucru a tabelului respectiv. Dacă masa nu este deschisă, ne va deschide masa. Mai important, va „aminti” că a deschis masa și, implicit, o va închide atunci când va fi distrusă. Clasa oferă suport pentru un parametru suplimentar care poate fi folosit pentru a specifica un nume de alias atunci când este necesar să deschideți un tabel cu un alias altul decât numele real al tabelului.

Clasa nu are proprietăți sau metode expuse și își face toată munca în metodele Init și Destroy. Prin crearea unui obiect bazat pe această clasă și definirea acestuia ca local, nu trebuie să scriem niciodată cod ca cel arătat mai sus.

Un cuvânt despre crearea obiectului selector

Un obiect selector poate fi creat în mod obișnuit, încărcând mai întâi fișierul de procedură în memorie și apoi folosind funcția CreateObject() ori de câte ori este nevoie de o instanță. Cu toate acestea, Versiunea 6.0 a Visual FoxPro a introdus o metodă alternativă, folosind funcția NewObject(), care vă permite să specificați biblioteca de clase din care o clasă ar trebui să fie instanțiată ca parametru. Deși este puțin mai lent, înseamnă că nu trebuie să încărcați și să păstrați fișierele de procedură în memorie

și este util atunci când trebuie să creați un obiect „din zbor”, ca acesta. Sintaxa pentru ambele metode este dată mai jos. (Rețineți că, cu NewObject(), dacă clasa nu este o bibliotecă de clase vizuale, Visual FoxPro așteaptă atât un nume „modul sau program” ca al doilea parametru, cât și un nume de aplicație sau un șir gol sau o valoare nulă ca al treilea. )

*** Folosind CreateObject()

SETĂ PROCEDURA LA ADITIVUL selalias

loSel = CREATEOBJECT('xSelAlias', <Alias>, [|<Table Name>])

*** Folosind NewObject()

loSel = NEWOBJECT('xSelAlias', 'selalias.prg', NULL, <Alias>, [|<Nume tabel>])

Un cuvânt de precauție - dacă utilizați mai multe instanțe ale acestei clase în aceeași procedură sau metodă pentru a deschide tabele, fie asigurați-vă că toate obiectele sunt create din aceeași zonă de lucru, fie că sunt eliberate în ordinea inversă celei în care au fost. instanțiat. Dacă nu faceți acest lucru, puteți ajunge într-o zonă de lucru care a fost selectată ca urmare a deschiderii unui tabel, dar care acum este goală.

Cum este construită clasa selectorului

După cum sa menționat în prezentarea generală, această clasă nu are proprietăți sau metode expuse și își face toată munca în metodele Init sau Destroy. Pe plan intern, folosește trei proprietăți protejate pentru a înregistra:

• 	zona de lucru în care a fost instanțiată

• 	alias-ul tabelului pe care îl gestionează

• 	dacă tabelul era deja deschis la instanțiere

Metoda Init a clasei selectoare

Metoda Init face patru lucruri. Mai întâi verifică parametrii. Un nume de alias este minimul care trebuie transmis, iar în absența celui de-al doilea parametru opțional - numele tabelului, se presupune că tabelul este numit la fel ca aliasul. Dacă este transmis, numele tabelului poate include o extensie și poate include, de asemenea, o cale. (Observați utilizarea assert în această parte a metodei. Obiectivul aici este de a avertiza dezvoltatorii despre erorile care pot apărea în sintaxa de apelare fără a afecta codul de timp de execuție.)

PROCEDURE INIT( tcAlias, tcTable )

LOCAL llRetVal

*** Niciun alias transmis - Bail Out

DACĂ ! VARTYPE( tcAlias ) = „C”

AFIRMĂ .F. MESAJ „Trebuie să treci un nume de alias la selectorul zonei de lucru”

RETURNARE .F.

ENDIF

tcAlias = UPPER( ALLTRIM( tcAlias ))

IF VARTYPE(tcTable) # "C" SAU EMPTY(tcTable)

tcTable = tcAlias

ALTE

tcTable = UPPER( ALLTRIM( tcTable ))

ENDIF

Apoi, verifică aliasul selectat în prezent. Dacă acesta este deja aliasul necesar, pur și simplu returnează o valoare de .f. iar obiectul nu este instanțiat. Motivul este pur și simplu că, dacă tabelul este deja deschis și selectat, oricum obiectul nu are nimic de făcut:

*** Dacă se află deja în zona de lucru corectă - nu faceți nimic

IF UPPER(ALLTRIM ( ALIAS() )) == tcAlias

RETURNARE .F.

ENDIF

Apoi determină dacă aliasul necesar este deja în uz și, dacă nu, încearcă să deschidă tabelul sub aliasul specificat. Dacă reușește, își setează proprietatea „IWasOpen” la .f. Acest lucru permite ca același tabel să fie deschis de mai multe ori sub aliasuri diferite. Dacă tabelul nu poate fi deschis, o valoare de .f. va fi returnat și obiectul nu va fi instanțiat. (NOTĂ: O versiune „de producție” a acestei clase ar trebui să verifice, de asemenea, dacă fișierul există și că este un tabel Visual FoxPro valid, înainte de a încerca să îl deschideți cu o comandă de utilizare. Un astfel de cod a fost deja acoperit în altă parte și a fost deliberat omisă din această clasă pentru a o menține cât mai simplă. Vezi funcția ISDBF() din Capitolul 7, „Cum se compară structurile a două tabele” pentru o soluție.)

*** Dacă Aliasul specificat nu este deschis - Deschideți-l

DACĂ ! FOLOSIT( tcAlias )

UTILIZAȚI (tcTable) DIN NOU ÎN 0 ALIAS (tcAlias) PARȚIAT

*** Și verificați!

llRetVal = USED( tcAlias )

*** Dacă deschiderea forțată, rețineți faptul

IF llRetVal

This.lWasOpen = .F.

ENDIF

ALTE

llRetVal = .T.

ENDIF

În cele din urmă, stochează numărul zonei de lucru selectate în prezent și numele alias-ului în proprietățile sale „nOldarea” și „cAlias” și comută la zona de lucru necesară. Prin urmare, obiectul este instanțiat numai atunci când totul a funcționat conform așteptărilor:

*** DACĂ OK, salvați zona de lucru curentă și

*** Acum deplasați-vă în zona de lucru specificată

IF llRetVal

This.nOldArea = SELECT()

SELECTARE (tcAlias)

Aceasta.cAlias = tcAlias

ENDIF

*** Stare returnare

RETURN llRetVal

ENDPROC

Clasa selector metoda Destroy

Metoda Destroy se ocupă de curățarea mediului. Dacă selectorul a deschis masa, aceasta este închisă - în caz contrar este lăsată deschisă. Zona de lucru în care a fost instanțiat obiectul este apoi selectată și obiectul eliberat:

PROCEDURA DISTRUGERE

Cu asta

*** Dacă masa este deschisă de acest obiect, închideți-l

DACĂ ! .Eram Deschis

UTILIZAȚI ÎN (This.cAlias)

ENDIF

*** Restaurați zona de lucru anterioară

DACĂ ! EMPTY( .nOldArea )

SELECTARE ( .nOldArea )

ENDIF

SE TERMINA CU

ENDPROC

Folosind clasa selectorului

Clasa este destinată să fie utilizată pentru a instanția un obiect local într-o procedură sau metodă ori de câte ori este necesar să se schimbe zonele de lucru. Programul exemplu (ChgArea.prg) arată cum poate fi utilizat:

**************************************************** ********************

* 	Program. ...: ChgArea.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Ilustrați utilizarea clasei SELALIAS pentru control

* 	..........:și schimbarea zonelor de lucru. Rezultatele de ieșire pe ecran

**************************************************** ********************

*** Asigurați-vă că suntem cu toții închiși

CLAR

ÎNCHID MABELE TOATE

*** Deschideți tabelul Clienți

UTILIZAȚI COMANDA sqlcli 1 ÎN 0

? „Folosirea Selectorului cu doar un alias”

? „FOLOSIȚI COMANDA sqlcli 1 ÎN 0”

? „Zona:”+PADL(SELECT(),2)+” Folosind tabelul „+JUSTSTEM(DBF())+” ca alias „+ALIAS() ?

*** Creați un obiect de selecție client

loSelCli = NEWOBJECT( 'xSelAlias', 'SelAlias.prg', NULL, 'SqlCli' )

? "loSelCli = NEWOBJECT('xSelAlias', 'SelAlias.prg', NULL, 'SqlCli' )"

? „Zona:”+PADL(SELECT(),2)+” Folosind tabelul „+JUSTSTEM(DBF())+” ca alias „+ALIAS()

*** Deschideți tabelul facturilor (temporar)

loSelInv = NEWOBJECT( 'xSelAlias', 'SelAlias.prg', NULL, 'SqlInv' )

"loSelInv = NEWOBJECT('xSelAlias', 'SelAlias.prg', NULL, 'SqlInv' )"

? „Zona:”+PADL(SELECT(),2)+” Folosind tabelul „+JUSTSTEM(DBF())+” ca alias „+ALIAS() ?

*** Acum închideți tabelul Facturi eliberând obiectul

LANSAți losSelInv

? „ELIBERAȚI losSelInv”

? "USED( 'SqlInv' ) => "+IIF( USED( 'SqlInv' ), "Încă în uz", "Nu este deschis")

?

*** Acum eliberați obiectul tabel Client

Eliberați loSelCli

? „LANSAți loselCli”

? "USED( 'SqlCli' ) => "+IIF( USED('SqlCli' ), "Încă în uz", "Nu este deschis")?

? „Zona:”+PADL(SELECT(),2)+” Folosind tabelul „+JUSTSTEM(DBF())+” ca alias „+ALIAS()

? „Apăsați o tastă pentru a șterge ecranul și a continua...”

INKEY(0, 'hm' )

CLAR

? „Folosirea Selectorului pentru a crea un alias”

„Zona:”+PADL(SELECT(),2)+” Folosind tabelul „+JUSTSTEM(DBF())+” ca alias „+ALIAS()

*** Deschideți din nou clienții sub noul alias

loSelCli = NEWOBJECT( 'xSelAlias', 'SelAlias.prg', NULL, 'Clients', 'SqlCli' )

? "loSelCli = NEWOBJECT('xSelAlias', 'SelAlias.prg', NULL, 'Clients', 'SqlCli')"

? „Zona:”+PADL(SELECT(),2)+” Folosind tabelul „+JUSTSTEM(DBF())+” ca alias „+ALIAS()

*** Deschideți tabelul facturilor (temporar)

loSelInv = NEWOBJECT( 'xSelAlias', 'SelAlias.prg', NULL, 'Facturi', 'SqlInv' )

? "loSelInv = NEWOBJECT('xSelAlias','SelAlias.prg', NULL, 'Facturi', 'SqlInv')" ? „Zona:”+PADL(SELECT(),2)+” Folosind tabelul „+JUSTSTEM(DBF())+” ca alias „+ALIAS() ?

*** Acum închideți tabelul Facturi eliberând obiectul

LANSAți losSelInv

? „ELIBERAȚI losSelInv”

? "USED('Facturi' ) => "+IIF( USED('Facturi' ), "Încă în uz", "Nu este deschis" )?

*** Acum eliberați obiectul tabel Client

Eliberați loSelCli

? „LANSAți loselCli”

"USED('Clients' ) => "+IIF( USED('Clients' ), "Încă în uz", "Nu este deschis" )

Zona:"+PADL(SELECT(),2)+" Folosind tabelul "+JUSTSTEM(DBF())+" ca alias "+ALIAS()

? „Apăsați o tastă pentru a șterge ecranul și a termina...”

INKEY(0, 'hm' )

CLAR
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Cum pot gestiona căile în mediul de date al unui formular?

Mediul de date al formularului oferă multe beneficii, inclusiv facilitatea de a deschide și închide automat tabelele, de a seta tamponarea tabelelor individuale și, în timpul proiectării, de a utiliza glisarea și plasarea pentru a crea controale legate de date pe un formular. Cu toate acestea, există o problemă perenă cu utilizarea mediului de date al formularului - modul în care gestionează problema căilor pentru tabelele pe care le conține este, cel puțin, complicat.

Fiecare cursor creat în mediul de date are două proprietăți care sunt implicate cu numele tabelului și informațiile despre cale, și anume „Database” și „CursorSource”. Cu toate acestea, ele sunt utilizate diferit în funcție de faptul dacă tabelul în cauză este liber sau legat de un container de bază de date. Modul real în care sunt stocate informațiile depinde de locația tabelelor în momentul proiectării, conform următoarelor reguli:

Tabelul 10.2 Proprietățile cursorului care determină locația datelor sursă

Tip tabel și locație 	Baza de dateCursorSource
Tabel legat, DBC pe unitatea curentă 	Cale relativă și Nume fișier al DBCNumele tabelului din DBC
Tabel legat, DBC pe o unitate diferită 	Calea absolută și Numele fișierului DBCNumele tabelului din DBC
Tabel gratuit pe unitatea curentă 	Cale relativă goală și numele fișierului DBF	
Tabel gratuit pe o unitate diferită 	Cale absolută goală și numele fișierului DBF	

Următoarele exemple arată rezultatele adăugării unui tabel la DE al unui formular în timp ce rulați o sesiune VFP cu unitatea „G:” setată ca unitate implicită și „\VFP60\” ca director curent:

[1] 	Free Table pe o altă unitate

Alias = „messageb”

Baza de date = ""

CursorSource = e:\vfp50\common\libs\messageb.dbf

[2] 	Tabel liber în subdirectorul directorului de lucru curent (G:\VFP60\)

Alias = „client1

Baza de date = ""

CursorSource = data\customer.dbf

[3] 	Tabel dintr-un DBC pe o unitate diferită

Alias = „demon”

Baza de date = c:\vfp60\ch08\ch08.dbc

CursorSource = „demon”

[4] 	Tabel dintr-un DBC de pe aceeași unitate, dar NU un subdirector al directorului de lucru (G:\VFP60\)

Alias = „clienți”

Baza de date = ..\samples\data\testdata.dbc

CursorSource = „clienți”

[5] 	Tabel dintr-un DBC din subdirectorul directorului de lucru curent (G:\VFP60\)

Alias = „clienți”

Baza de date = data\testdata.dbc

CursorSource = „clienți”

În timpul rulării, Visual FoxPro va încerca întotdeauna să folosească mai întâi informațiile salvate cu cursorul, dar dacă fișierul nu poate fi găsit în locația specificată, va continua să caute toate căile disponibile.

Soluția „fără cod”!

Răspunsul ușor la această problemă este, prin urmare, să păstrați toate tabelele (libere sau legate) și containerele bazei de date în același director și să vă asigurați că este definit ca un subdirector al directorului dumneavoastră de dezvoltare. Acest lucru asigură că Visual FoxPro stochează doar calea relativă pentru tabele. (Vezi exemplele 2 și 5 de mai sus.)

Când distribuiți aplicația dvs., asigurați-vă că un subdirector (numit același cu cel utilizat în timpul dezvoltării) este creat sub directorul principal al aplicației și că toate fișierele de date sunt instalate acolo. Cu toate acestea, există de multe ori când această soluție pur și simplu nu este posibilă, cel mai evident atunci când aplicația este rulată pe mașini client, dar folosind date partajate stocate pe un server. Deci, ce putem face în privința asta?

Soluția hard-coded!

Mediul de date nativ al unui formular nu poate fi subclasat (deși putem, desigur, să ne creăm propriile clase de mediu de date în cod). Aceasta înseamnă că nu există nicio modalitate de a scrie cod într-o clasă de formular în timpul proiectării pentru a gestiona rezoluția căilor, deoarece un astfel de cod ar trebui să fie plasat în metoda de mediu de date BeforeOpenTables. (De ce BeforeOpenTables? Deoarece metoda OpenTables creează obiectele cursor și apoi apelează BeforeOpenTables după ce obiectele sunt create, dar înainte ca informațiile din ele să fie folosite pentru a deschide efectiv tabelele.) Deci o abordare este să adăugați un cod la metoda BeforeOpenTables a fiecărei formular pentru a seta căile pentru tabelele conținute, după cum este necesar. Acest lucru va funcționa, dar pare mai degrabă un „mod de modă veche de a face asta. În afară de orice altceva, menținerea unei cereri cu o mulțime de formulare ar face o întreprindere majoră. Trebuie să existe o cale mai bună!

Soluția pentru obiecte bazate pe date!

Dacă nu putem subclasa mediul de date nativ, poate că am putea crea propria noastră clasă pentru a se ocupa de lucru și pur și simplu să limităm codul care trebuie adăugat la fiecare instanță a unei clase de formular la o singură linie? Într-adevăr, putem face exact asta și, dacă folosim un tabel pentru a păstra informații despre cale, putem simplifica foarte mult sarcina de întreținere a aplicației. O astfel de soluție este prezentată în secțiunea următoare a acestui capitol.

Clasa manager de căi de date

Clasa managerului de căi de date este proiectată pentru a fi instanțiată ca obiect tranzitoriu în metoda BeforeOpenTables a unui mediu de date Form. Funcția sa este de a scana prin toate obiectele membre ale mediului de date și, pentru fiecare obiect cursor pe care îl găsește, să efectueze o căutare într-un tabel „sistem” separat, care definește căile care vor fi utilizate pentru tabelele sale în timpul rulării. Deși mai trebuie să adăugăm cod la metoda BeforeOpenTables a mediului de date în fiecare formă pe care o creăm, trebuie să adăugăm doar o linie. Codul executat este conținut într-o singură clasă și folosește un singur tabel cu structură predefinită. Întreținerea este, așadar, o problemă minoră atunci când adoptați această strategie.

Tabelul de gestionare a căilor

Prima componentă de care avem nevoie pentru a implementa strategia descrisă mai sus este tabelul de căutare care va conține informațiile pe care dorim să le folosească Visual FoxPro în timpul rulării. Acest tabel a fost numit (în mod imaginativ) „datapath.dbf” și, deși l-am inclus în containerul bazei de date a proiectului, în mod normal, recomandăm ca acesta să fie folosit ca tabel liber. Structura este următoarea:

Structura pentru: C:\VFP60\CH10\DATAPATH.DBF

DBC: CH10.DBC

CDX : DATAPATH.CDX

Indici asociați

*** CHEIE PRIMARĂ: CTABLE: UPPER(CTABLE)

ISDEL: DELETED()

Detalii câmp

CTABLE C ( 20,0 ) NOT NULL && Nume tabel - fie Nume DBC, fie Nume fișier DBF

SET_PATH C ( 60,0 ) NOT NULL && Drive și Path

SET_DBC C ( 20,0 ) NOT NULL && Nume DBC (doar tabele legate)

SET_TABLE C ( 20,0 ) NOT NULL && Numele tabelului în DBC (Bound Tables)

&& Numele și extensia fișierului (tabele gratuite)

Pentru a accelera căutările, tabelul este indexat în câmpul cu numele tabelului și are un index pe DELETED(). Deoarece acest tabel ar fi probabil configurat local pe o mașină client (pentru a gestiona mapările unităților individuale), problema reducerii indicilor mari pe DELETED() în rețea nu este probabil să apară. Avem tabelul nostru exemplu populat așa cum este ilustrat în Figura 10.2 de mai jos:

1 	CtableSetpathSet dbcSet table|
! : 	FATEMP\CH10.DBCSQLCLI
SQLCON 	FATEMP\CH10.DBCSQLCON
SQLINV 	FATEMP\CH10.DBCSQLINV
SQLPHO 	FATEMPSCH10.DBCSQLPHO
INIFILE 	FATEMPS 		¡ÑIFILE.DBF

Figura 10.2 Tabelul de mapare a căilor de date

Clasa de gestionare a căilor (Exemplu: chgpaths.scx)

Clasa reală, ca și selectorul zonei de lucru, își face treaba direct în metoda Init sau metodele numite din Init și nu are metode sau proprietăți expuse. Aceasta înseamnă că, atunci când este instanțiat, obiectul își îndeplinește automat funcția și poate fi apoi eliberat. Clasa definește două proprietăți protejate pentru utilizarea sa în interior, o matrice pentru a păstra referințe la obiecte la cursoarele dataenvironment și o proprietate pentru a stoca referința la obiectul dataenvironment apelant în sine.

Principiul din spatele funcționării sale este că primește o referință la mediul de date apelant (ca parametru) și validează că referința este atât un obiect valid, cât și de fapt se referă la un obiect a cărui clasă de bază este „mediul de date”. DE apelant este apoi analizat pentru a obține o referință la fiecare obiect cursor, care este stocat în tabloul intern. După ce a deschis tabelul de căutare, pasul final este de a prelua pe rând referința fiecărui cursor și de a determina numele tabelului pe care se bazează (folosește JUSTSTEMO pentru a returna numele din proprietatea CursorSource).

Numele tabelului este apoi căutat în tabelul de mapare și, în funcție de datele găsite (dacă există), proprietățile Baza de date și CursorSource sunt actualizate. Codul real folosit este:

* 	Program. ... :DPathMgr.prg

* 	Compiler...:Visual FoxPro 06.00.8492.00 pentru Windows

* 	Abstract...:Folosește tabelul de căutare pentru a obține căile corecte pentru tabele

* 	..........:la timpul de rulare, setați căile în DE Cursor Object

* 	..........:Cali din BeforeOpenTables Metoda unui formular DE

* 	..........:Se așteaptă ca o referință la DE să fie transmisă - poate folosiNEWOBJECT():

* 	..........:loPathSet = NEWOB JECT ('dPathMgr', 'dpathmgr.prg',NULL,THIS)

DEFINIȚI CLASA Relația DPathMgr AS *** Definiți Proprietățile Protejate *** *** Matrice pentru lista de Cursore PROTEJATE aCursore[1]

aCursors[1] = NULL

*** Obiect de referință la DE

ODE PROTEJAT

oDe = NULL

Metoda Init este folosită pentru a controla procesarea și mai întâi verifică parametrul transmis pentru a se asigura că este o referință la un obiect de mediu de date. Apoi, se calizează metoda GetTcibles și, dacă se găsesc tabele, se calizează OpenRefTable pentru a deschide tabelul de căutare. În cele din urmă, folosește metoda SetPaths pentru a verifica de fapt fiecare cursor și a vedea dacă a fost definită o nouă cale pentru el:

PROCEDURA Init( toDe )

InCursori LOCAL

*** Verificați parametrul

IF VARTYPE( toDe ) = "O"

*** Să aibă o referință de obiect validă

This.oDe = toDe

IF LOWER( This.oDE.BaseClass ) # "datamediu"

*** Dar nu este un DE!

AFIRMĂ .F. MESAJ „DPathMgr Class Necesită o referire la „ ;

+ CHR(13) + "Obiect DataEnvironment care îl apelează."

RETURNARE .F.

ENDIF

ALTE

*** Hopa - Nici măcar un obiect

RETURNARE .F.

ENDIF

*** Câte cursoare sunt?

lnCursors = This.GetTables()

IF lnCursori < 1

*** Nimic de făcut - așa că întoarce-te bine

ÎNTOARCERE

ENDIF

*** Verificați DataPath Table și deschideți-l dacă este necesar

DACĂ ! This.OpenRefTable()

*** Nu se poate găsi tabelul de referință

RETURNARE .F.

ENDIF

*** Setați căile pentru Cursore

This.SetPaths( lnCursors )

ÎNTOARCERE

ENDPROC

OpenRefTable încearcă în mod explicit să deschidă tabelul DataPath. Acest lucru ar putea, dacă este necesar, să fie parametrizat, dar nu putem vedea niciun beneficiu imediat mare pentru a face acest lucru (mai degrabă opusul de fapt). Pot exista situații în care mai multe tabele de mapare ar fi necesare de către o aplicație și atunci ar fi pe deplin adecvat să se transmită un parametru pe care să-l folosească tabelul. Cu toate acestea, făcând acest lucru pierzi unul dintre principalele beneficii ale acestei abordări, și anume că codul care trebuie inserat în formularele BeforeOpenTables nu ar mai fi același pentru fiecare formular:

PROCEDURA PROTEJATA openreftable

*** Deschideți tabelul de referință

DACĂ ! USED('DataPath')

UTILIZAȚI DIN NOU calea de date ÎN 0 NOUPDATE PARTASATĂ

ENDIF

RETURN USE('DataPath')

ENDPROC

Metoda GetTables folosește referința obiectului stocat la mediul de date apelant pentru a popula o matrice cu toate obiectele membre. Acesta este apoi scanat și referințele la obiectele cursor sunt stocate în proprietatea matricei. Metoda returnează numărul de cursore pe care le-a găsit:

PROCEDURĂ PROTEJATĂ GetTables

LOCAL ARRAY laObj[1]

LOCAL lnObjCnt, lnCnt, loObj, InRows, lcObjName

*** Obțineți o listă cu toate obiectele din DE

lnObjCnt = AMEMBERS( laObj, This.oDe, 2)

*** Scanați lista

lnRows = 0

PENTRU lnCnt = 1 LA lnObjCnt

*** Verificați dacă acest obiect este de fapt un Cursor

loObj = EVAL( „Acest.oDe.” + laObj[lnCnt] )

IF loObj.BaseClass = "Cursor"

*** Este, așa că păstrați referința la matricea internă

*** Adăugați un nou rând la matricea cursorelor

lnRows = lnRows + 1

DIMENSIUNEA This.aCursors[ lnRows, 1]

This.aCursors[lnRows] = loObj

ENDIF

URMĂTORUL

*** Returnează numărul de cursore

RETURN lnRows

ENDPROC

Metoda SetPaths este locul în care se face căutarea în tabelul de mapare și rezultatele sunt utilizate pentru a reseta proprietățile Baza de date și CursorSource ale fiecărui cursor în consecință. Dacă nu există nicio intrare în tabelul de căutare, proprietățile cursorului nu sunt modificate în niciun fel:

PROCEDURĂ PROTEJATĂ SetPaths( tnCursors )

LOCAL lnCnt, loObj, lcTable

*** Scanați lista

FOR lnCnt = 1 TO tnCursors

*** Preluați Referința obiectului din matrice

loObj = This.aCursors[lnCnt]

*** Găsiți numele tabelului

lcTable = UPPER( JUSTSTEM( loObj.CursorSource ))

*** Căutați numele în tabelul de referință care listează

*** de unde ar trebui preluate datele

IF SEEK(lcTable, "datapath", "ctable")

*** Avem o referință pentru acest tabel!

DACĂ ! EMPTY( set_dbc )

*** Avem o masă legată

loObj.Database = ALLTRIM( datapath.set_path ) ;

+ ALLTRIM( DataPath.set_dbc )

loObj.CursorSource = ALLTRIM(DataPath.set_table)

ALTE

*** Trebuie să fie o masă liberă

loObj.Database = ""

loObj.CursorSource = ALLTRIM( datapath.set_path ) ;

+ ALLTRIM( DataPath.set_table )

ENDIF

ENDIF

URMĂTORUL

ENDPROC

ENDDEFINE

Folosind managerul de căi de date

Exemplul de formular ChgPaths.SCXfolosește managerul de căi de date pentru a modifica căile tabelelor care au fost adăugate în mediul său de date. Pentru a experimenta acest lucru, pur și simplu copiați CH10.DBC (și toate tabelele) într-o locație alternativă și schimbați câmpul set_path din сору tabelului DataPath care rămâne în locația originală. Singurul cod care a fost adăugat la mediul de date al formularului este linia unică din metoda BeforeOpenTables, după cum urmează:

NEWOBJECT('dpathmgr', 'dpathmgr.prg', NULL, THIS )

care instanțează obiectul manager de căi de date și îi transmite o referință la mediul de date.

După cum se arată în Figura 10.3, configurația originală pentru fiecare tabel din formularul dataenvironment este derivată din tabelele locale din directorul C:\VFP60\CH10. Figura 10.4 arată rezultatul rulării formularului și, așa cum era de așteptat, tabelele din formular sunt extrase dintr-o unitate și un director complet diferit.

Figura 10.3 Configurare pentru tabelele SQLCLI în formularul exemplu DE

Figura 10.4 Exemplul de formular care rulează - rețineți că tabelele sunt acum desenate dintr-o sursă diferită
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Cum pot gestiona formularele și barele de instrumente din aplicația mea?

Probabil că există tot atâtea răspunsuri la această întrebare câte dezvoltatori care scriu aplicații folosind Visual FoxPro. O parte cheie a oricărui cadru de aplicație este mecanismul de gestionare a formularelor și toate cadrele includ un „Manager de formulare” de un fel. Mecanismul de implementare a acestuia va depinde de cadrul dvs., dar există anumite sarcini de bază pe care orice astfel de obiect manager trebuie să le îndeplinească:

• 	Instanciarea formularelor (indiferent dacă se bazează pe SCX sau VCX)

• 	Urmărirea formularului (și instanța unui formular) este activ în prezent

• 	Asigurarea că bara de instrumente adecvată este disponibilă

• 	Adăugarea și eliminarea formularelor în propria listă de formulare active pe măsură ce sunt inițializate sau eliberate

Desigur, există multe alte funcții care ar putea fi efectuate de managerul de formulare (de exemplu, adăugarea/eliminarea elementelor din lista de ferestre sau formularele „în cascadă” pe măsură ce sunt inițializate), dar cele patru enumerate mai sus constituie funcționalitatea de bază pe care clasa trebuie să o facă. oferi.

Pentru a implementa un manager de formulare, este necesar să se creeze o „subclasă gestionată”, atât pentru Formulare, cât și pentru Barele de instrumente, astfel încât codul suplimentar pentru a interacționa cu managerul să poată fi izolat. Următoarele secțiuni prezintă codul pentru aceste clase și pentru o clasă de manager de formulare care se va ocupa de toate sarcinile de bază descrise mai sus. Această clasă a fost concepută pentru a fi instanțiată ca un obiect „global”, care nu este singurul mod de a face acest lucru, dar este cel mai simplu de ilustrat. De asemenea, am fi putut implementa metodele necesare ca parte a unei clase mai ample de „manager de aplicații” sau chiar am fi gestionat instanțierea și referirea managerului de formulare indirect printr-un obiect de aplicație.
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Clasa de formulare gestionate

Formularele destinate să funcționeze cu managerul de formulare aparțin unei clase speciale ÇxFrmStdManaged' din GenForms.vcx). Pe lângă codul necesar din metodele Init, Activate și Destroy, sunt necesare trei proprietăți personalizate și două metode pentru interacțiunea cu Managerul de formulare, după cum urmează:

Tabelul 10.3 Proprietăți și metode personalizate pentru clasa de formulare gestionate

Denumiți 	PEM Scop
cInsName 	PropertyInstance Nume, atribuit de managerul de formulare atunci când formularul este inițializat
cTbrName 	PropertyName al barei de instrumente folosită de formular (dacă există)
lOneInstance 	PropertyWhen .T împiedică Form Mgr să creeze mai multe instanțe ale formularului
ReportAction 	MethodCall a managerului FormAction
CheckFrmMgr 	MethodReturns o referință de obiect către managerul de formulare

Proprietățile personalizate

• 	Proprietatea cInsName este folosită pentru a stoca numele instanței atribuite de managerul de formulare, unui formular când este inițializat. Managerul de formulare stochează atât numele formularului, cât și numele instanței atribuite în colecția sa internă. Acest lucru se adresează mai multor instanțe ale unui formular, oferind managerului de formulare un mijloc de a identifica în mod unic fiecare instanță a unui anumit formular.

• 	CTbrName este populat la momentul proiectării cu numele clasei barei de instrumente asociată cu formularul. Această proprietate va fi citită de managerul de formulare în timpul execuției pentru a determina care, dacă există, barele de instrumente sunt necesare și pentru a se asigura că atunci când un anumit formular este activat, bara de instrumente corectă este afișată.

• Proprietatea lOneInstance poate fi setată pentru a indica managerului de formulare că formularul este o singură instanță. Când managerul de formulare este instruit să instanțieze un formular care există deja în colecția sa, pur și simplu va restaura și activa formularul existent dacă această proprietate este setată.

Clasa de formulare metoda ReportAction

Această metodă oferă „punctul unic de contact” între formular și managerul de formulare. Poate fi apelat prin orice metodă de formular care trece un parametru care indică tipul de acțiune cerut de la managerul de formulare (în exemplul nostru, aceasta ar fi fie „activare”, fie „distruge”):

LPARAMETERS tcAction

LOFrmMgr

*** Verificați parametrul

IF VARTYPE( tcAction ) # "C"

AFIRMĂ .F. MESAJ „Metoda Form’s ReportAction trebuie apelată cu o acțiune necesară”

ÎNTOARCERE

ENDIF

*** Acum gestionați apelul către Managerul de formulare

CU ThisForm

*** Obțineți o referință la Managerul formularului

loFrmMgr = .CheckFruMgr()

IF VARTYPE( loFruMgr ) = "O"

*** Spune Managerului de formulare să facă din acesta formularul activ

loFrmMgr.FormAction( tcAction, .cInsName )

ALTE

*** Fără formular Manager, așa că nu este nevoie de nimic special

ENDIF

SE TERMINA CU

Responsabilitatea pentru verificarea existenței managerului de formulare este transmisă metodei CheckFrmMgr, care returnează fie referința corespunzătoare a obiectului, fie o valoare nulă. Dacă este returnată o referință validă, metoda apelează apoi metoda FormAction a managerului și transmite atât acțiunea necesară, cât și numele instanței formularului pentru a oferi o referință clară pentru managerul de formulare.

Clasa de formulare metoda Init

Metoda Init clasei de formular se așteaptă să primească fie un obiect parametru care conține o proprietate numită cInsName, fie un șir de caractere care este numele care trebuie stocat în proprietatea sa cInsName:

LPARAMETRI tuParam

*** Metoda clasei se așteaptă ca Numele instanței să fie transmis

*** fie ca „cInsName” într-un obiect parametru sau ca șir.

*** Chiar s-ar putea testa aici, dar ce naiba! Trăiește periculos!

*** (De fapt, testul ar trebui făcut fie în instanță, fie în subclasă)

IF VARTYPE( tuParam ) = "O"

*** Stocați proprietatea cInsName pentru a forma proprietatea

ThisForm.cInsName

tuParam. cInsName

RETURNARE .T.

ENDIF

*** Dacă nu este un obiect, este un șir?

IF VARTYPE( tuParam ) = "C"

*** Stocați ceea ce este transmis pentru a forma proprietatea

ThisForm.cInsName = tuParam

RETURNARE .T.

ALTE

*** Avem ceva grav în neregulă aici!

AFIRMĂ .F. ;

MESAJ „Clasa de formular folosită necesită un nume de instanță” + CHR(13) ;

+ "să fie generat de managerul de formulare și transmis formularului." + CHR(13);

+ „Avortarea inițializării formularului”

RETURNARE .T.

ENDIF

Aceasta înseamnă că orice instanță a formularului care necesită parametri suplimentari trebuie să extragă, din propria listă de parametri, numele instanței generate de managerul de formulare și să îl transmită înapoi clasei după cum urmează:

LPARAMETERS toParams

*** Extrageți numele instanței din obiectul parametru

DACĂ VARTYPE ( toParams ) = 'O' AND PEMSTATUS (toParams, 'cInsName', 5 )

*** Treceți numele instanței până la metoda clasei părinte

DODEFAULT( toParams.cInsName )

IF toParams.nParamCount > 0

*** Extrageți parametri suplimentari denumiți „tuParml” prin „tuParmn”

ENDIF

ALTE

*** Nu s-a specificat niciun nume de instanță

*** Luați orice măsură este adecvată la momentul respectiv

ENDIF

*** Faceți orice altceva este nevoie aici

Un avantaj major al utilizării unui obiect parametru ca acesta, așa cum am discutat în capitolul 2, este că vă permite să utilizați parametrii „numiți”, ceea ce simplifică codul necesar pentru a citi valorile transmise.

Clasa de formulare Metodele Activate, Release și QueryUnload

În plus, clasa include două linii de cod în ambele metode Activate și Release pentru a iniția comunicarea cu managerul de formulare. Codul, în fiecare caz, apelează metoda ReportAction și transmite numele metodei care se execută:

ThisForm.ReportAction( JUSTEXT( PROGRAM() ))

DODEFAULT()

În cele din urmă, metoda QueryUnLoad din această clasă include un apel explicit la metoda Release pentru a se asigura că, indiferent dacă utilizatorul iese din formular, Managerul de formulare este notificat. (Asta pentru ca

QueryUnl.oad ocolește în mod normal metoda Release. Următorul eveniment comun atât pentru Release, cât și pentru QueryUnload este Destroy, iar acesta este prea târziu pentru Managerul de formulare.)

Copyright 2000 de către Marcia Akins, Andy Kramek și Rick Schummer Toate drepturile rezervate

Clasa de bară de instrumente gestionată

Utilizarea barelor de instrumente într-o aplicație este dificil de abordat generic. Indiferent dacă utilizați bare de instrumente diferite pentru diferite formulare sau dacă utilizați o singură bară de instrumente și activați/dezactivați opțiunile după cum este necesar, va afecta detaliile de proiectare. Cu toate acestea, indiferent de abordarea pe care o adoptați, bara de instrumente va trebui să interacționeze cu formularele dvs. Deoarece Managerul de formulare controlează formularele, pare absolut rezonabil să aibă grijă și de barele de instrumente, care, prin urmare, trebuie să fie proiectate în consecință. Clasa noastră de bare de instrumente abstracte gestionate ("xTbrStdManaged" în GenClass.vcx) a fost configurată după cum urmează.

Mai întâi, proprietatea ControlBox a barei de instrumente a fost setată la .f. asigurându-se astfel că un utilizator nu poate închide din neatenție o bară de instrumente (acum responsabilitatea managerului de formulare) și barei de instrumente i s-a dat o sesiune de date privată. Au fost adăugate trei metode personalizate și ceva cod adăugat la metoda nativă Activare a clasei, după cum urmează.

Clasa de instrumente Activate metoda

Problema abordată aici este să ne asigurăm că ori de câte ori o bară de instrumente este activată, aceasta se va sincroniza cu orice formă este activă în prezent pe ecran. Metoda Activare a unei bare de instrumente este apelată ori de câte ori este afișată bara de instrumente și, deoarece managerul de formulare va gestiona barele de instrumente apelând metodele Afișare și Ascundere, putem folosi aceasta pentru a apela metoda care va sincroniza setările barei de instrumente cu formularul curent :

*** Sincronizați bara de instrumente cu formularul activ în prezent

*** Activarea este apelată de la Show(), așa că se va declanșa întotdeauna

*** Când Managerul de formulare apelează Toolbar.Show()

This.SetDataSession()

Metoda SetDataSession din clasa barei de instrumente

Când este apelată, această metodă fie va seta bara de instrumente la aceeași sesiune de date ca și formularul activ în prezent și apoi va apela metoda personalizată SynchWithForm a barei de instrumente. Dacă niciun formular nu este activ, pur și simplu apelează metoda personalizată SetDisabled:

loForma locală

*** Obțineți referință la formularul activ

IF TYPE ( "_Screen.ActiveForm" ) = "O" ȘI ! ISNULL( _Screen.ActiveForm )

*** Obțineți referință la Formularul activ

loForm = _Screen.ActiveForm

*** Forțați sesiunea de date la aceeași

This.DataSessionID = loForm.DataSessionID

*** Metoda de sincronizare a apelurilor pentru a gestiona setările barei de instrumente

This.SynchWithForm( loForm )

ALTE

*** Fără formular, așa că dezactivează bara de instrumente!

*** Notă: acest lucru nu ar trebui să se întâmple niciodată, deoarece managerul de formulare ar trebui

*** se ocupă întotdeauna de vizibilitatea barei de instrumente

This.SetDisabled()

ENDIF

Metoda SynchWithForm din clasa barei de instrumente

Aceasta este pur și simplu o metodă șablon care trebuie completată într-o clasă concretă. Este apelat de metoda personalizată SetDataSession atunci când este găsit un formular activ și este locul în care veți gestiona orice detalii de sincronizare (activare/dezactivare butoane și așa mai departe). Primește, ca parametru, o referință la forma activă în prezent.

Metoda SetDisabled din clasa barei de instrumente

Această metodă oferă un comportament implicit pentru a dezactiva toate controalele de pe bara de instrumente atunci când nu este găsit niciun formular activ. Acest lucru nu ar trebui să se întâmple niciodată când rulați sub controlul managerului de formulare, dar comportamentul este prevăzut oricum.
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Clasa manager de formulare

Clasa de manager de formulare ilustrată aici are o interfață publică foarte simplă. Există doar trei metode personalizate ÇDoForm', 'FormAction' şi 'ReleaseAll'). Metoda DoForm este destinată să fie apelată în mod explicit în cod și este responsabilă pentru crearea formularelor și a barelor de instrumente asociate acestora. Metoda FormAction este apelată automat din metodele Activate și Destroy din clasa de formulare gestionată, dar ar putea fi extinsă cu ușurință pentru a gestiona alte acțiuni dacă este necesar. Metoda ReleaseAll este concepută pentru a fi apelată din procesul de închidere, dar ar putea fi apelată și dintr-un element de meniu „Închide toate formularele”. Această clasă este concepută pentru a funcționa împreună cu clasele Formular gestionat și Bara de instrumente gestionată descrise în secțiunile precedente. Codul real este discutat în secțiunile următoare.

Definirea managerului de formulare și metoda Init

Clasa definește două matrice și patru proprietăți, toate fiind protejate după cum urmează:

Tabelul 10.4 Proprietăți și metode personalizate pentru clasa de formulare manager de formulare

Denumiți 	PEM Scop
aFmList 	Array PropertyThe Forms Collection
aTbList 	Array Property Colecția de bare de instrumente
nFmCount 	PropertyNumăr de formulare conținute în colecția de formulare
nTbCount 	PropertyNumărul de bare de instrumente conținute în colecția de bare de instrumente
nFmIndex 	PropertyIndex la formularul activ în prezent în Forms Collection
nTbIndex 	PropertyIndex la bara de instrumente activă în prezent din colecția de bare de instrumente

Metoda Init inițializează pur și simplu aceste proprietăți:

DEFINEȚI CLASA xFrnMgr CA RELATIE

MATRICE PROTEJATĂ aFmList[1,4], aTbList[1,3]

PROTEJAT nFmIndex, nFmCount, nTbCount, nTbIndex

FUNCȚIE Init

Cu asta

*** Inițializați proprietăți

.aFmList = "" && Colectare formulare

.nFmCount = 0 && Număr de formulare gestionate

.nFmIndex = 0 && Index în colecție pentru forma curentă

.aTbList = "" && Colectia Barei de instrumente

.nTbCount = 0 && Numărul barei de instrumente

.nTBIndex = 0 && Index în Colecția pentru bara de instrumente curentă

SE TERMINA CU

ENDFUNC

Metoda DoForm manager de formulare

Această metodă personalizată este locul în care managerul de formulare creează formulare și orice bare de instrumente asociate. Este cea mai mare metodă unică din clasă, dar nu se pretează cu adevărat la o descompunere ulterioară. Metoda permite trecerea a până la trei parametri, dar în mod normal ne-am aștepta să transmitem un singur obiect parametru. Singurul motiv pentru această structură este de a simplifica apelarea metodei direct dintr-un element de meniu.

Primii doi parametri sunt utilizați pentru numele și metoda care urmează să fie utilizate pentru instanțierea formularului.

Când apelați un SCX, trebuie transmis doar numele formularului, cu excepția cazului în care există parametri suplimentari, deoarece valoarea implicită pentru al doilea va fi .f. - care va invoca mecanismul do form. Dacă formularul urmează să fie instanțiat dintr-o clasă, al doilea parametru trebuie întotdeauna transmis explicit ca .T.

Primul lucru pe care îl face această metodă este să verifice parametrii și să genereze (folosind sys(2015)) un șir de caractere valid care va fi folosit atât pentru referința obiectului la formular, cât și pentru numele „instanței” acestuia: ******* **************************************************** ******

*** xFrmMgr::DoForm( tcFmName, tlIsClass, tuParm1, tuParm2, tuParm3 )

*** Metoda expusă pentru a rula un formular

*** Prevedere pentru 3 parametri, dar în mod normal ar fi de așteptat doar 1 (ca

*** Un obiect parametru)

**************************************************** *************

FUNCȚIA DoForm ( tcFmName, tlIsClass, tuParm1, tuParm2, tuParm3 )

LOCAL lnFormParams, lcFmName, loFmRef, lnFmIdx, llRetVal, lnCnt

Cu asta

*** Verificați parametrii

IF VARTYPE( tcFmName ) # "C"

*** Numele formularului nu este furnizat!

AFIRMĂ .F. MESAJ ;

„Numele unui formular sau al unei clase de formulare,” + CHR(13) ;

+ „Trebuie să fie transmis la Managerul de formulare DoForm ()”

RETURNARE .F.

ENDIF

*** Setați steagul de întoarcere

llRetVal = .T.

*** Numele și tipul formularului trebuie să fie prezente, câți parametri de formular?

lnFormParams = PCOUNT () - 2

Următorul lucru este să verificați dacă formularul a fost deja instanțiat și, dacă da, dacă formularul a fost definit ca „instanță unică”. Modul în care managerul gestionează astfel de formulare este să reactiveze pur și simplu instanța existentă, să seteze bara de instrumente (dacă există) și să iasă:

*** Verificați dacă avem deja acest formular?

.nFmIndex = .FmIdx(tcFmName)

*** Dacă îl avem, este o singură instanță

DACĂ .nFmIndex > 0

*** Obțineți o referință la formular și vedeți dacă putem

*** au mai multe cazuri ale acestuia.

loFmRef = .aFmList[.nFmIndex, 1]

CU loFmRef

*** Verificați dacă formularul este cu o singură instanță

DACA .lOneInstance

*** Restabiliți forma dacă este minimizată

DACĂ .WindowState > 0

.WindowState = 0

ENDIF

*** Forțați să ajungeți sus

.AlwaysOnTop = .T.

*** Activați formularul

.Activati()

*** Anulează Force To Top

.AlwaysOnTop = .F.

*** Sortați barele de instrumente, transmiteți numele barei de instrumente (dacă există)

.SetToolBar( .aFmList[.nFmIndex, 4])

*** Și Ieșire chiar acum

RETURN llRetval

ENDIF

SE TERMINA CU

ENDIF

Dacă formularul nu este deja instanțiat sau dacă este, dar nu este o singură instanță, atunci este necesar un formular nou.

Mai întâi generăm referința obiectului și numele instanței, apoi construim un obiect parametru pentru formularul:

*** Este necesară fie prima rulare a formularului, fie o nouă instanță

*** Creați obiectul parametru

*** Generați un nume de instanță și o referință la obiect

STORE SYS(2015) TO lcFmName, loFmRef

*** Creați obiectul parametru

oParams = NEWOBJECT( „xParam”, „genclass.vcx” )

CU oParams

*** Mai întâi numele instanței

.AddProperty( 'cInsName', IcFmName )

*** Adăugați un număr de proprietăți

.AddProperty( 'nParamCount', lnFormParams )

*** Adăugați orice parametri suplimentari care urmează să fie transferați în formular

DACA lnFormParams > 0

FOR lnCnt = 1 TO lnFormParams

IcPName = "tuParm" + ALLTRIM(STR(lnCnt))

.AddProperty( lcPName, &lcPName )

URMĂTORUL

ENDIF

SE TERMINA CU

În cele din urmă, putem crea formularul în sine. Parametrul tlIsClass este utilizat pentru a decide dacă formularul necesar este un fișier SCX sau o clasă și pentru a instanția formularul în mod corespunzător:

*** Instanciați formularul

IF tlIsClass

*** Creați ca o clasă

loFmRef = CREATEOBJECT( tcFmName, oParams )

ALTE

*** Rulați ca formular folosind clauzele NAME și LINKED

DO FORM (tcFmName) NAME loFmRef CU oParams LEGATE

ENDIF

*** Actualizați colecția cu noile detalii de formular

IF VARTYPE( loFmRef ) = "O"

*** DA - am primit un formular, așa că creșteți numărul de formulare și populați colecția

.nFmCount = .nFmCount + 1

DIMENSIUNE .aFmList[.nFmCount, 4]

.aFmList[.nFmCount, 1] = loFmRef && Referință obiect

.aFmList[.nFmCount, 2] = lcFmName && Nume instanță

.aFmList[.nFmCount, 3] = tcFmName && Nume formular

.aFmList[.nFmCount, 4] = UPPER.( ALLTRIM ( loFmRef.cTbrName )) && Bara de instrumente de utilizat

*** Faceți din aceasta forma activă

.nFmIndex = .nFmCount

*** Afișați noul formular

loFmRef.Show()

ALTE

*** Inițializarea formularului a eșuat din anumite motive

llRetVal = .F.

ENDIF

După crearea formularului, verificăm că formularul a fost creat într-adevăr, apoi completăm colecția de formulare cu informațiile relevante. Ultimul lucru de făcut este să gestionați afișarea barelor de instrumente, care se face apelând metoda DoToolBar:

*** În cele din urmă, rezolvați cerința barei de instrumente

IF llRetVal

.DoToolBar( .aFmList[.nFmCount, 4] )

ENDIF

RETURN llRetVal

SE TERMINA CU

ENDFUNC

Metoda DoToolbar a managerului de formulare

Această metodă este apelată numai atunci când este creată o nouă formă sau o nouă instanță a unui formular. Funcția sa este de a actualiza colecția Barei de instrumente dacă noul formular necesită o bară de instrumente. Aceasta poate implica creșterea numărului unei bare de instrumente existente sau crearea unei noi bare de instrumente. Aceeași metodă tratează ambele situații:

**************************************************** *************

*** xFrmMgr::DoToolBar( tcTbName )

*** Metodă protejată pentru a crea sau a seta bara de instrumente numită activă

*** Apelat la crearea unui formular

**************************************************** *************

FUNCȚIE PROTEJATĂ DoToolBar( tcTbName )

Cu asta

LnTbIdx LOCAL

*** Avem nevoie de o bară de instrumente?

IF EMPTY( tcTbName )

*** Nu este necesară nicio bară de instrumente, ascunde-le pe toate

.SetToolBar( "" )

ÎNTOARCERE

ENDIF

*** Verificați dacă avem deja bara de instrumente

lnTbIdx = .TbIdx( tcTbName )

DACĂ lnTbIdx > 0

*** Îl avem deja pe acesta, așa că activează-l

*** Și crește-i contorul cu unul

.aTbList[ lnTbIdx, 2] = .aTbList[ lnTbIdx, 2] + 1

ALTE

*** Trebuie să-l creăm și să-l adăugăm la colecție

.nTbCount = .nTbCount + 1

DIMENSIUNE .aTbList[ .nTBCount, 3]

.aTbList[ .nTbCount, 1] = CREATEOBJECT( tcTbName ) && Ref obiect

.aTbList[ .nTbCount, 2] = 1 && Contor bară de instrumente

.aTbList[ .nTbCount, 3] = UPPER( ALLTRIM( tcTbName )) && Numele barei de instrumente

ENDIF

*** Faceți bara de instrumente cea activă

.nTbIndex = .nTbCount

.SetToolBar( .aTbList[ .nTbCount, 3] )

SE TERMINA CU

ENDFUNC

Această metodă apelează metoda SetToolBar pentru a sorta afișarea barelor de instrumente și transmite fie numele barei de instrumente necesare (dacă există una), fie un șir gol. Acesta din urmă face ca metoda SetToolBar să ascundă toate barele de instrumente existente.

Metoda FormAction manager de formulare

Această metodă este apelată dintr-un formular pentru a solicita acțiune de la managerul de formulare. Sunt așteptați doi parametri, primul este acțiunea necesară și al doilea este numele instanței formularului care solicită acțiunea. Clasa de formulare gestionate apelează această metodă ori de câte ori un formular este activat sau eliberat pentru a notifica managerului o schimbare a stării, trecând numele metodei de apelare ca prim parametru. Acțiunea întreprinsă depinde de apel și acțiuni suplimentare pot fi furnizate cu ușurință aici:

**************************************************** *************

*** xFrmMgr::FormAction( tcAction, tcInsName )

*** Metoda expusă pentru gestionarea cererilor de formulare

**************************************************** *************

FUNCȚIE FormAction( tcAction, tcInsName )

Cu asta

LnFmIndex LOCAL

*** Avem acest formular?

lnFmIndex = 0

lnFmIndex = .FmIdx(tcInsName)

*** Dacă îl avem

DACA Index lnFm > 0

FACE CAZ

CASE UPPER( tcAction ) = „ACTIVARE”

*** Faceți din aceasta forma activă

.nFmIndex = lnFmIndex

.SetToolBar( .aFmList[.nFmIndex, 4])

CASE UPPER( tcAction ) = „RELEASE”

*** Ștergeți formularul din colecție

.nFmIndex = lnFmIndex

.ClearForm( .aFmList[.nFmIndex, 1] )

IN CAZ CONTRAR

AFIRMĂ .F. ;

MESAJUL „Acțiune: „ + tcAction + „ a fost transmis către Administrator formular” ;

+ CHR(13) + „Dar nu este recunoscut”

RETURNARE .F.

ENDCASE

ALTE

*** Formularul nu a fost pornit de Managerul de formulare

*** Nimic de făcut în privința asta

ENDIF

ÎNTOARCERE

SE TERMINA CU

ENDFUNC

Metoda managerului de formulare ReleaseAll

După cum sugerează numele, ultima dintre metodele principale eliberează pur și simplu toate formularele și barele de instrumente pe care managerul de formulare le are în colecțiile sale. Acesta este de obicei apelat din procesul de oprire, dar poate fi folosit și pentru a oferi opțiunea „Șterge tot” într-un meniu:

**************************************************** *************

*** xFrmMgr::ReleaseAll

*** Metodă expusă pentru eliberarea TOATE formularele deținute de Managerul de formulare

*** Folosit la închiderea unei aplicații cu formulare încă deschise

**************************************************** *************

FUNCȚIE ReleaseAll

CU ASTA

LOFmRef, loTbRef

.nFmIndex = .nFmCount

*** Eliberați toate formularele

FACEȚI CÂND .nFmIndex > 0

*** Verificați că mai avem un obiect formular

loFmRef = .aFmList[.nFmIndex, 1]

IF VARTYPE( loFmRef ) = "O"

*** Dă-i drumul

loFmRef.Release()

ENDIF

.nFmIndex = .nFmIndex - 1

ENDDO

*** Reinițializați colecția de formulare

DIMENSIUNE .aFmList[1,4]

.nFmCount = 0

.nFmIndex = 0

.aFmList = ""

*** Eliberați toate barele de instrumente

.nTbIndex = .nTbCount

FACEȚI CÂND .nTbIndex > 0

*** Verificați că mai avem un obiect bară de instrumente

loTbRef = .aTbList[.nTbIndex, 1]

IF VARTYPE( loTbRef ) = "O"

*** Dă-i drumul

loTbRef.Release()

ENDIF

.nTbIndex = .nTbIndex - 1

ENDDO

*** Reinițializați colecția de bare de instrumente

DIMENSIUNE .aTbList[1,3]

.nTbCount = 0

.nTbIndex = 0

.aTbList = ""

RETURNARE .T.

SE TERMINA CU

ENDFUNC

Managerul de formulare ShowForms și HideForms metode

Aceste două metode personalizate suplimentare sunt expuse în managerul de formulare pentru a oferi un mecanism pentru ascunderea și re-afișarea tuturor formularelor vizibile. Acest lucru este util dacă rulați un raport pentru previzualizare și nu doriți ca niciun formular existent să interfereze cu vizibilitatea raportului. Metodele sunt în esență

la fel și treceți în buclă prin colecția de formulare setând proprietatea vizibilă a tuturor formularelor. Metoda hide se termină prin apelarea SetToolBar cu un șir gol pentru a elimina orice bare de instrumente existente. Metoda show apelează metoda Show a ultimului formular care a fost activ pentru a-l restaura și bara de instrumente asociată:

**************************************************** *************

*** xFrmMgr::HideForms

*** Metodă expusă pentru a ascunde toate formularele deținute de Managerul de formulare

*** Folosit atunci când rulează Previzualizarea tipăririi cu mai multe formulare deschise

**************************************************** *************

FUNCȚIA HideForms

Cu asta

LOCAL nIndex, loFmRef

nIndex = .nFmCount

*** Ascunde toate formularele

FACEȚI CÂND nIndex > 0

*** Verificați că mai avem un obiect formular

loFmRef = .aFmList[nIndex, 1]

IF VARTYPE( loFmRef ) = "O"

*** Ascunde-l

loFmRef.Vizibil = .F.

ENDIF

nIndex = nIndex - 1

ENDDO

*** Ascunde toate barele de instrumente

.SetToolBar( "" )

SE TERMINA CU

ENDFUNC

**************************************************** *************

*** xFrmMgr::ShowForms

*** Metodă expusă pentru a afișa toate formularele deținute de Managerul de formulare

*** Folosit la închiderea previzualizării tipăririi cu mai multe formulare deschise **************************************** ************************** FUNCȚIA ShowForms

Cu asta

LOCAL nIndex, loFmRef

nIndex = 0

*** Afișați toate formularele

DO WHILE nIndex < .nFmCount

nIndex = nIndex + 1

*** Verificați că mai avem un obiect formular

loFmRef = .aFmList[nIndex, 1]

IF VARTYPE( loFmRef ) = "O"

*** Arat-o

loFmRef.Vizibil = .T.

ENDIF

ENDDO

*** Restaurați ultimul formular activ

.aFmList[ .nFmIndex, 1].Show()

SE TERMINA CU

ENDFUNC

Metoda ClearForm manager de formulare

Această metodă personalizată protejată elimină un formular și bara de instrumente asociată acestuia din colecțiile de formulare și bare de instrumente. Este apelat din metoda FormAction atunci când un formular anunță managerul că este eliberat:

**************************************************** *************

*** xFrmMgr::ClearForm( toFmRef )

*** Metodă protejată pentru a elimina un formular din colecție

**************************************************** *************

FUNCȚIE PROTEJATĂ ClearForm(toFmRef)

Cu asta

*** Anulează dacă nu este un Obiect

IF Type('toFmRef') # "O" SAU ISNULL(toFmRef)

RETURNARE .F.

ENDIF

*** Verificați pentru o bară de instrumente asociată

lcTbName = .aFmList[.nFmIndex, 4]

DACĂ ! EMPTY(lcTbName)

.ClearToolBar(lcTbName)

ENDIF

*** Ștergeți intrarea de colectare a formularelor

.nFmCount = .nFmCount - 1

DACĂ .nFmCount < 1

*** Reinițializați matricea dacă aceasta a fost ultima formă

DIMENSIUNE .aFmList[1,4]

.nFmCount = 0

.nFmIndex = 0

.aFmList = ""

ALTE

*** Doar redimensionați-l

=ADEL(.aFmList, .nFmIndex )

DIMENSIUNE .aFmList[.nFmCount ,4]

ENDIF

*** Resetați indexul = numărul de formulare

*** (Următoarea activare a formularului o va reseta oricum)

.nFmIndex = .nFmCount

SE TERMINA CU

ENDFUNC

Metoda managerului de formulare FmIdx

Această metodă personalizată protejată este apelată fie cu o referință de obiect la un formular, fie cu numele instanței unui formular și caută în colecția de formulare pentru a găsi și returna indexul corect în colecția acelui formular:

**************************************************** *************

*** xFrmMgr::FmIdx( tuFmRef )

*** Scanați colecția de formulare pentru referință care poate

*** fie o referință la un obiect la un formular sau un nume de instanță

*** Returnează numărul RÂNDUL, dacă este găsit

**************************************************** *************

FUNCȚIE PROTEJATĂ FmIdx(tuFmRef)

Cu asta

LOCAL lnElem, lnIdx

lnIdx = 0

DACĂ ! ISNULL(tuFmRef) ȘI .nFmCount > 0

ACTIVAT EXACT

*** Scanați matricea

IF TYPE("tuFmRef") = "O"

lnElem = ASCAN(.aFmList, tuFmRef.cInsName)

ALTE

lnElem = ASCAN(.aFmList, tuFmRef)

ENDIF

*** Calculați numărul rândului

DACĂ lnElem > 0

lnIdx = ASUBSCRIPT(.aFmList, lnElem, 1)

ENDIF

SETĂ EXACT OFF

ENDIF

RETURN lnIdx

SE TERMINA CU

ENDFUNC

Metoda managerului de formulare TbIdx

Această metodă personalizată protejată îndeplinește aceeași funcție pentru barele de instrumente ca și metoda fmIdx pentru formulare. Returnează numărul de index al unei bare de instrumente din colecția de bare de instrumente. Cu toate acestea, deoarece această metodă este întotdeauna apelată în contextul unei forme cunoscute, se așteaptă întotdeauna ca numele barei de instrumente să fie transmis ca parametru. (Numele barei de instrumente este stocat în a patra coloană a colecției de formulare.)

**************************************************** *************

*** xFrmMgr::TbIdx( tcTbName )

*** Scanați colecția Barei de instrumente pentru referință, care va fi

*** să fie numele barei de instrumente necesare

*** Returnează numărul RÂNDUL, dacă este găsit

**************************************************** *************

FUNCȚIE PROTEJATĂ TbIdx(tcTbName)

Cu asta

LOCAL lnElem, lnIdx

lnIdx = 0

*** Verificați că avem un nume și cel puțin o bară de instrumente înregistrată

DACĂ ! EMPTY(tcTbName) ȘI .nTbCount > 0

ACTIVAT EXACT

*** Scanați matricea

InElem = ASCAN(.aTbList, tcTbName)

*** Calculați numărul rândului

DACĂ lnElem > 0

lnIdx = ASUBSCRIPT(.aTbList, lnElem, 1)

ENDIF

SETĂ EXACT OFF

ENDIF

*** Returnați numărul de rând corespunzător

RETURN lnIdx

SE TERMINA CU

ENDFUNC

Metoda SetToolbar a managerului de formulare

Această metodă personalizată protejată este responsabilă pentru controlul afișării barelor de instrumente pe ecran. Se așteaptă să primească fie numele unei bare de instrumente, fie un șir gol, ca parametru. Metoda trece pur și simplu prin colecția de bare de instrumente și ascunde toate barele de instrumente, cu excepția celei specificate. Dacă nu este specificat nimic, toate barele de instrumente sunt ascunse:

**************************************************** *************

*** xFrmMgr::SetToolBar( tcTbrName )

*** Metodă protejată pentru a activa bara de instrumente numită

*** Trecerea unui șir gol ascunde toate barele de instrumente

*** Apelat la activarea unui formular

**************************************************** *************

FUNCȚIE PROTEJATĂ SetToolBar( tcTbName )

Cu asta

LnCnt LOCAL

*** Parcurgeți colecția barei de instrumente și ascundeți toate, cu excepția celei necesare

FOR lnCnt = 1 TO .nTBCount

FACE CAZ

CAZ EMPTY( .aTbList[ lnCnt, 3 ] )

*** Nu sunt definite bare de instrumente - Nu faceți nimic

*** Necesar pentru a evita compararea cu un șir gol!

CASE EMPTY(tcTbName)

*** Nu este necesară Bara de instrumente, așa că ascunde-o

.aTbList[lnCnt, 1].Hide()

CASE tcTbName == .aTbList[ lnCnt, 3 ]

*** Îl vrem pe acesta, așa că arată-l

.aTbList[lnCnt, 1].Show()

IN CAZ CONTRAR

*** Nu-l vreau pe acesta, așa că ascunde-l

.aTbList[lnCnt, 1].Hide()

ENDCASE

URMĂTORUL

SE TERMINA CU

ENDFUNC

Metoda ClearToolbar a managerului de formulare

Această metodă personalizată protejată corespunde metodei ClearForm și elimină o bară de instrumente din colecția de bare de instrumente a managerului de formulare. Cu toate acestea, deoarece barele de instrumente sunt instanțiate o singură dată, eliminarea unui formular care are o bară de instrumente asociată nu înseamnă neapărat că bara de instrumente ar trebui eliberată. Alte forme mai pot solicita acest lucru. Această metodă tratează ambele situații doar prin decrementarea contorului (deținut în coloana a doua a colecției barei de instrumente), cu excepția cazului în care acesta scade sub 1. În această situație, bara de instrumente este eliberată și întregul rând este șters din colecție:

**************************************************** *************

*** xFrmMgr::ClearToolBar( tcTbrName )

*** Metodă protejată pentru a activa bara de instrumente numită

*** Trecerea unui șir gol ascunde toate barele de instrumente

*** Apelat la activarea unui formular

**************************************************** *************

FUNCȚIE PROTEJATĂ ClearToolBar( tcTbName )

Cu asta

LnIdx LOCAL

*** Găsiți rândul în colecția Barei de instrumente

lnIdx = 0

lnIdx = .TbIdx( tcTbName )

DACĂ lnIdx = 0

*** Această bară de instrumente nu este înregistrată oricum

ÎNTOARCERE

ENDIF

*** Decrementează contorul

.aTbList[ lnIdx, 2] = .aTbList[ lnIdx, 2] - 1

DACĂ .aTbList[ lnIdx, 2] = 0

*** Fără altă referință, așa că eliberați Bara de instrumente

.aTbList[ lnIdx, 1].Release()

.nTbCount = .nTbCount - 1

DACĂ .nTbCount < 1

*** Reinițializați matricea dacă aceasta a fost ultima

DIMENSIUNE .aTbList[1,3]

.nTbCount = 0

.nTbIndex = 0

.aTbList = ""

ALTE

*** Doar redimensionați-l

=ADEL(.aTbList, lnIdx )

DIMENSIUNE .aTbList[.nTbCount , 3]

ENDIF

ENDIF

SE TERMINA CU

ENDFUNC
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Utilizarea managerului de formulare (Exemplu: FmgrTest.prg)

După cum sa menționat în introducerea acestei secțiuni, clasa managerului de formulare este proiectată pentru a fi instanțiată ca obiect global. Acest lucru a fost făcut pentru a evita necesitatea ca managerul să treacă o referință la sine la fiecare formular creat - cu toate capcanele potențiale pentru colectarea gunoiului pe care aceasta le-ar implica. Rezultatul este că clasa de formulare gestionată trebuie să știe să verifice prezența managerului de formulare și aceasta este gestionată în acea clasă prin metoda CheckFrmMgr. Acceptăm că acesta poate fi văzut ca un mod „greșit” de a face lucrurile, dar considerăm că „mai simplu este mai bine” în acest caz. Adoptarea unei metode diferite ar necesita doar o schimbare la o singură metodă în clasa de formulare și considerăm că beneficiile simplității depășesc pierderea flexibilității pentru acest tip de obiect manager.

Exemplul de program instanțiază un obiect manager de formulare și îl folosește pentru a crea trei perechi de formulare. Fiecare pereche constă din aceeași formă definită atât ca SCX, cât și ca Clasă. O pereche nu are bară de instrumente, o pereche necesită o bară de instrumente „buton”, iar a treia folosește o bară de instrumente „combo box”. Codul de bază este:

SETATE CLASSLIB LA genclass, Fmgrtest ADITIV

LANSA goFrmMgr

PUBLIC goFrnrt-lgr

*** Creați obiectul Fonem Manager

goFrmMgr = newobject('xFrmMgr', 'formmgr.prg', NULL)

*** Acum rulați niște formulare atât Class cât și SCX

*** Cu și fără bare de instrumente.

*** Rețineți că formele bazate pe clasă necesită o logică .T. ca parametru 2

goFrmMgr,Doform('btnbarfm')

goFrmMgr,Doform( 'btnbarfm' ,.T.)

goFrmMgr.Doform( 'ebobarfm' )

goFrmMgr.Doform( 'ebobarfm' ,.T.)

goFrmMgr ,Doform('notbarfm')

goFrmMgr ,Doform(' notbarfm' , .T.)

Codul real eșalonează, de asemenea, formularele de pe ecran, astfel încât să prezinte aspectul ilustrat în Figura 10.5 de mai jos:

finiri



Ijj Plain Form, Run as Form, Button

'țfjf Formă simplă, Run as Class, Button

Figura 10.5 Rularea mai multor formulare în Managerul de formulare

Pe măsură ce diferitele forme se concentrează, acestea sunt aduse în partea de sus și bara de instrumente asociată este activată, așa cum se arată în următoarele ilustrații:

Figura 10.6 Formularul SCX cu bara de instrumente asociată

Formă simplă, Rulare ca formular, Instrument Buton

Jn]xJ

lÿFormular simplu, Run as Form, ComboBox Toolbc

^fFormă simplă. Rulați ca formă. Nu prea



^*ι|

Figura 10.7 Formular VCX cu bara de instrumente asociată

Comportamentul formularului poate fi testat și apelând direct metodele HideForms și ShowForms ale managerului de formulare:

GoFrmMgr . HideForms ( ) și goFrmMgr.ShowForms()

Formularele pot fi, de asemenea, eliberate făcând clic pe butonul de închidere și reinstanțate dacă este necesar. Pentru a elibera toate formularele, utilizați metoda ReleaseAllQ a managerului de formulare:

goFrmMgr.ReleaseAll ()
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Cum pot urmări și gestiona erorile?

Probabil cel mai cuprinzător tratament al strategiei de gestionare a erorilor din Visual FoxPro este lucrarea excelentă a lui Doug Hennig, „Error Handling in Visual FoxPro”, care este disponibilă pentru descărcare, împreună cu exemplu de cod, de pe site-ul său web la www.stonefield.com. Nu are rost să reiterăm ceea ce spune Doug, iar cel mai bun sfat pe care vi-l putem oferi este că, dacă aveți nevoie de o schemă completă de gestionare a erorilor, luați această lucrare și studiați-o.

Deci, ce putem oferi aici în schimb? Ei bine, bănuim că, în practică, majoritatea aplicațiilor (spre deosebire de instrumente sau utilitare) nu încearcă, sau chiar au nevoie, să gestioneze erorile. Acest lucru se datorează faptului că cele mai multe dintre erorile care vor apărea într-o aplicație pot fi erori de cod (adică erori de logică), erorile de consistență a datelor rulând o secundă aproape. Prioritățile în aceste situații sunt, prin urmare, să protejeze integritatea datelor, să informeze utilizatorul că ceva a mers prost și să închidă aplicația cu grație și siguranță. Ceea ce avem cu adevărat nevoie pentru această situație este ceva care să înregistreze ceea ce s-a întâmplat și să ofere cât mai multe informații despre starea sistemului atunci când a apărut eroarea.

Deoarece Visual FoxPro este o bază de date, nu pare nerezonabil să credem că acest tip de informații ar trebui înregistrate într-un tabel, astfel încât informațiile să poată fi folosite pentru a genera rapoarte, înregistrări remedieri și așa mai departe. Prin urmare, despre ce vorbim cu adevărat este „înregistrarea erorilor” mai degrabă decât „tratarea erorilor!” Desigur, trebuie să ne bazăm în continuare pe gestionarea erorilor Visual FoxPro pentru a ne spune când ceva a mers prost. Nu orice eroare pe care Visual FoxPro o detectează va necesita închiderea aplicației, așa că există încă un element de manipulare despre toate acestea - deși poate nu atât de mult pe cât ați putea crede.

Clasificarea erorilor Visual FoxPro

Gestionarea implicită a erorilor Visual FoxPro oferă peste 700 de erori recunoscute, dar acestea nu sunt chiar clasificate într-un mod util. Pentru a încerca să folosim mai bine erorile standard, am creat un tabel (frrmsg.dbf) care conține toate numerele de eroare standard ale Visual FoxPro și textul asociat. În acest tabel sunt incluse trei câmpuri suplimentare pentru „Categorie”, „Tip” și „Acțiune” pentru a ne oferi următoarea structură:

ERRNUM N ( 4)

ERRCAT C ( 20)

ERRTYPE C ( 20)

ERAȚIE C ( 10)

ERRTEXT C (200)

Am clasificat erorile în una dintre cele cinci categorii enumerate mai jos.

• 	Erori de proiectare: Acestea sunt lucruri care pot apărea numai în timpul dezvoltării unei aplicații și pe care, prin urmare, nu ne-am aștepta să le întâlnim în niciun alt moment. Acestea sunt, în principal, erori de compilare sau „în uz”. Exemplu: Eroare 1169: „Fișierul de proiect este doar pentru citire”.

• 	Erori dezvoltatori: Elementele din această categorie apar din erori de cod sau de logică. Multe dintre acestea vor fi prinse în testare și apar din nepăsare, oboseală, cod insuficient defensiv sau presupuneri nevalide din partea dezvoltatorului. Remedierea acestor erori va fi

necesită invariabil modificări ale codului sursă. Exemplu: Eroare 1127: „Trebuie să utilizați o expresie logică cu o clauză FOR sau WHILE.”

• 	Erori de timp de rulare: Această categorie include lucruri care ar fi greu de detectat la momentul proiectării și care ar putea să nu fie prinse nici măcar în timpul testării. Cele mai multe dintre acestea sunt legate de fișiere lipsă sau invalide sau de operațiuni care pot avea succes într-un mediu de dezvoltare, dar care pot eșua în timpul rulării. Ca și în cazul erorilor dezvoltate, remedierea necesită de obicei modificări ale codului sursă. Exemplu: Eroare 109 „Înregistrarea este utilizată de un alt utilizator.”

• 	Erori de sistem: Acestea sunt lucruri care în mod normal nu sunt cauzate direct de erorile din codul sursă, ci apar din cauza problemelor legate de mediul de sistem sau de resurse. Majoritatea acestora pot fi gestionate cu adevărat doar prin închiderea aplicației. Exemplu: Eroare 1986 „Memoria GDI este scăzută, închideți unul sau mai multe Windows și încercați din nou.”

• 	Erori utilizator: Doar 11 din cele 700 de erori standard ar putea fi cu adevărat atribuite acestei categorii. Acestea sunt erori la care, în mod normal, ne-am aștepta să apară doar ca rezultat al unei acțiuni a utilizatorului. Majoritatea ar trebui să poată fi rezolvate fără a fi nevoie să închidă aplicația, deși este puțin probabil ca o soluție generică să poată fi concepută pentru a le gestiona. Exemplu: Eroare 1523 „Execuția a fost anulată de utilizator”.

Cu toate acestea, problema este că unele erori pot apărea din diferite motive. De exemplu, eroarea 1152 „Nu se poate accesa tabelul selectat”. ar putea fi cauzată de pierderea conexiunii la rețea (o eroare de „sistem”), dar și pentru că tabelul folosit ca sursă de rând pentru o casetă combo sau listă a fost închis prea devreme (fie o eroare „dezvoltator”, fie o eroare „durată de rulare” ).

Pentru fiecare eroare am adăugat o acțiune standard care ar fi fie să închidem întreaga aplicație, fie să anulăm procesul curent sau să rezolvăm eroarea. Rețineți că acestea nu sunt soluții, ci doar o indicație a severității așteptate a erorii!

Textul mesajului de eroare din acest tabel este pur și simplu mesajul standard pe care Visual FoxPro îl generează. Acestea sunt rareori „utilizabile” și vă recomandăm să înlocuiți mesajele standard cu ceva mai potrivit pentru situația dvs. (Dar acesta este cu siguranță un „exercițiu pentru cititor”).

În cele din urmă, acolo unde a fost posibil, am atribuit fiecărei erori un „Tip” legat de situația în care este cel mai probabil să apară, de exemplu „SQL”, „Print” „Index” sau „Tabel”. Doar jumătate din erori au putut fi atribuite în acest fel și nu toate aceste sarcini sunt neapărat exclusive, dar am simțit că a fost totuși un exercițiu util.

Erori de înregistrare (Exemplu: TrackErr.prg, ErrorLog.prg)

Există trei probleme de rezolvat atunci când creați un program de înregistrare a erorilor. În primul rând, ce ar trebui să fie înregistrat? Răspunsul scurt este „pe cât posibil”! Este ușor să ignori informațiile superflue dintr-un jurnal de erori, dar de obicei este foarte dificil, dacă nu imposibil, să recreezi condițiile exacte în care a apărut o eroare. Cu cât puteți aduna mai multe informații despre ceea ce sa întâmplat, în momentul în care se întâmplă, cu atât mai ușor va fi rezolvată problema.

În al doilea rând, unde ar trebui să fie stocat jurnalul? Nu există un răspuns generic la această întrebare, dar soluția pe care o preferăm este să includem o intrare în fișierul INI al aplicației. Acesta ar trebui să definească atât numele, cât și locația jurnalului de erori și trebuie citit o singură dată când aplicația este pornită (consultați subiectul Manager de fișiere INI, în acest capitol, pentru detalii). Rezultatul poate fi stocat fie într-o variabilă globală, fie într-o proprietate a obiectului aplicației, pentru a fi utilizat ulterior. Un beneficiu esențial de a proceda astfel este că permite fiecărui utilizator să configureze un jurnal local de erori, dacă este necesar. (util în special pentru dezvoltatori și

testeri) fără a compromite capacitatea dumneavoastră de a menține un jurnal de erori centralizat pentru aplicație în ansamblu.

A treia problemă este cum ar trebui creat jurnalul de erori? Există două opțiuni de bază și fiecare are un anumit merit. Am putea folosi un tabel și am putea scrie o înregistrare pentru fiecare eroare direct în el. Beneficiul evident al acestei abordări este că se pretează la analiză și raportare, iar detaliile soluțiilor și remedierilor pot fi chiar stocate în același tabel. Problema este că, mai ales într-un sistem mare, există întotdeauna pericolul de a intra în conflicte atunci când încercați să accesați masa. Fiecare înregistrare va implica, în mod necesar, o cantitate mare de date și ultimul lucru pe care doriți să îl întâmpinați atunci când încercați să înregistrați o eroare este să ridicați alta!

Alternativ, am putea genera pur și simplu un fișier text cu detaliile fiecărei erori și, într-un tabel, să înregistrăm un rezumat al acelei erori împreună cu o referință la fișierul de ieșire. În general, ne place mai mult această abordare, deoarece este cea mai flexibilă și menține dimensiunea tabelului de jurnal de erori la minimum. O idee deosebit de bună pe care am văzut-o a fost că ori de câte ori a fost generat un fișier de eroare, acesta a fost trimis automat prin e-mail liderului echipei de dezvoltare.

Clasa noastră de înregistrare a erorilor, care este definită ca o clasă non-vizuală (ErrorLog.prg') adoptă a doua abordare și utilizează un tabel pentru a înregistra informații rezumate și un fișier text generat automat pentru a înregistra detaliile despre eroare și starea sistemului. Rețineți că nu am încercat să gestionăm situația în care apare o eroare în rutinele de tratare a erorilor. Nu numai că gestionarea unei astfel de erori este o problemă complexă în sine, ci depășește cu mult domeniul de aplicare al acestei clase particulare de acoperit. Următoarele secțiuni discută elementele principale ale clasei.

Tabelul „jurnal de erori”.

Acest tabel este utilizat de clasa de înregistrare a erorilor pentru a înregistra informații rezumative despre fiecare eroare care apare și are următoarea structură:

LOGSID Integer 4 && Număr ID eroare

LOGDTIME DateTime 8 && ștampila dată/ora

LOGERRNUM Întregul 4 && Număr de eroare VFP

LOGERRPROG Caracter 60 && Program în care a apărut eroarea

LOGERRLINE Întregul 4 && Numărul liniei în care a apărut eroarea

LOGERRUSER Caracter 20 && ID utilizator

LOGERRTXT Caracter 60 && Cale/Nume fișier în jurnal de erori

Un ID unic este generat pentru fiecare eroare care este înregistrată în acest tabel. Acest ID este apoi folosit ca parte a numelui fișierului text care înregistrează detaliile erorii pentru a oferi un mijloc simplu de referință încrucișată.

Utilizarea clasei de înregistrare a erorilor (errorlog.prg)

Această clasă se bazează pe clasa de bază Visual FoxPro „Formset”, astfel încât să i se ofere o sesiune de date privată. (Proprietățile FormCount și Visible au fost protejate și setate la o și, respectiv, .f.). Când clasa este instanțiată, deschide tabelele Jurnal de erori și Mesaje de eroare (fără tamponare) în sesiunea sa privată de date și determină calea în care ar trebui să fie scris fișierul jurnal și numele aplicației. În mod normal, instanțiem obiectul de înregistrare a erorilor la pornirea aplicației și îi atribuim o referință globală:

Eliberați goErrorLog

PUBLIC goErrorLog

goErrorLog = NEWOBJECT( 'xErrLog', 'errorlog.prg', NULL )

Clasa are o singură metodă personalizată expusă, metoda „LogError” și două proprietăți personalizate expuse, cNextAction și cUserMsg.

Setarea de eroare a lui Visual FoxPro este apoi îndreptată către un program de wrapper simplu care va primi DataSession, Programul și Numărul de linie în care a apărut eroarea și va apela metoda LogError, trecând parametrii, astfel:

ON ERROR DO TrackErr WITH SET("DATASESSION"), PROGRAM(), LINENO()

Obiectul de înregistrare a erorilor inserează o înregistrare în tabelul de jurnal de erori și scrie informațiile detaliate într-un fișier text. Apoi își completează proprietățile expuse cu mesajul și următoarea acțiune din tabelul personalizat cu mesaje de eroare. Programul wrapper citește apoi aceste proprietăți și este luată acțiunea corespunzătoare. Avantajul acestei abordări este că separă procesul de înregistrare în jurnal de cel al comunicării direct cu utilizatorul și ne permite să folosim clasa de înregistrare a erorilor în situațiile în care simpla afișare directă a unei casete de mesaj nu ar fi adecvată.

Programul TrackErr.prg arată de obicei cam așa:

**************************************************** ********************

* 	Program. ...: TrackErr.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Program apelat de ON ERROR pentru a înregistra detaliile erorii

* 	..........:ON ERROR DO TrackErr WITH SET("DATASESSION"), PROGRAM(), LINENO()

**************************************************** ********************

LPARAMETERS tnDSID, tcProgram, tnLineNo

LOCAL lcNextAction, lcUserMsg

IF VARTYPE( goErrorLog ) = "O"

*** Metoda de înregistrare a apelurilor

goErrorLog.LogError( tnDSID, tcProgram, tnLineNo )

*** Acum verificați rezultatele

lcNextAction = goErrorLog.cNextAction && Următoarea acțiune este necesară

lcUserMsg = goErrorLog.cUserMsg && Text mesaj utilizator

*** Luați orice acțiune este adecvată

*** De obicei, aceasta ar fi afișarea unui mesaj pentru utilizator

*** Și fie Reîncercați, fie Închideți

MESSAGEBOX(lcUserMsg, 16, „Eroare de aplicație”)

ALTE

MESSAGEBOX( „Înregistrarea erorilor nu este disponibilă”, 16, „Eroare de sistem” )

ENDIF

Fișierul text creat constă dintr-un antet și șase secțiuni de detalii, după cum urmează:

********* EROARE NOUĂ: 22/12/99 09:50:44 *******************

Eroare: 1925: membru necunoscut TXTOUTPUT.

la linia 29 din FRMCHGPATHS.SETFORM

Cod sursă: ThisForm.txtOutPut.Value

Utilizator: TLC HOME # andykr

Categorie: Dezvoltator

Tip:

Acțiune: Endproc

**************************************************** *************

[1] 	*** Memory dump: LIST MEMORY

[2] 	*** Dump de date

[3] 	*** Lanț de apelare

[4] 	*** Conținutul clipboard-ului

[5] 	*** Dump obiect: LIST OBIECTE

[6] 	*** Starea sesiunii de date: STARE LISTĂ

Programul TestErr.prg, inclus în exemplul de cod pentru acest capitol, setează obiectul de înregistrare a erorilor și apoi generează o eroare.
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Cum pot simplifica transmiterea de mesaje utilizatorilor mei?

Visual FoxPro ne oferă două mecanisme încorporate pentru a comunica cu utilizatorii noștri. În primul rând, există comanda WAIT WINDOW, care este cea mai potrivită pentru gestionarea mesajelor de stare și informații. În al doilea rând, este funcția MESSAGEBOXO, care oferă diferite formate ale unei forme modale care conține text și necesită o anumită acțiune din partea utilizatorului. Ambele sunt destul de utilizabile și, deși diferitele setări opționale pentru funcția меззадеьохо nu sunt ușor de reținut, pare inutil să încercați să „reinventați roata” atunci când este vorba de gestionarea mesajelor, prin conceperea unui înlocuitor pentru aceste două instrumente native.

Cu toate acestea, un lucru pe care ar trebui să-l luăm în considerare (mai ales în contextul componentelor сом, arhitecturii n-tier și aplicațiilor multiple „front-end”) este că ne-am dori cu adevărat să evităm codificarea calis explicit la funcții precum MESSAGEBOXO și WAIT WINDOW. La urma urmei, ambele funcții presupun că rulați într-un mediu în care conceptul de „fereastră” înseamnă ceva și este posibil să nu fie întotdeauna cazul.

De asemenea, dorim să eliminăm textul mesajului real din codul programului nostru prin extragerea acestuia într-un tabel. Acest lucru nu numai că ne permite să reutilizam mesajele, ci ajută și să menținem consecvența mesajelor în aplicațiile noastre - astfel încât să nu cerem utilizatorului să „Confirme modificările” într-un loc și să „Salveze modificările” în altul. De asemenea, face schimbarea textului mesajului real mai ușoară și, dacă trebuie să gestionați mai multe limbi, este singura modalitate practică de a face acest lucru. Următoarele secțiuni subliniază construcția și utilizarea clasei noastre de gestionare a mesajelor bazate pe tabel.

Pe cale de a șterge D<

Delețiile, odată comise, nu pot fi recuperate. Sunteți pe cale să comiteți o eliminare. Vă rugăm să confirmați că doriți cu adevărat să distrugeți aceste date complet și în cele din urmă?

доИздИдг = 	('хИздИдг1, 1 шздтпдг . prg1 ,)

InChoice = доИздИдг.ShoHsg(103□)

Figura 10.8 Clasa de gestionare a mesajelor simple

Tabelul de mesaje standard (msgtable.dbf)

Acest tabel este folosit pentru a stoca toate informațiile relevante pentru mesajele interfeței cu utilizatorul pe care le creăm. Este definit ca o tabelă liberă pe care, deoarece este întotdeauna doar pentru citire în timpul execuției, îl construim în

exe. În acest caz, schimbăm beneficiile de a avea tabelul ca parte a unui DBC pentru viteza de acces la

timpul de rulare. Structura tabelului este foarte simplă:

MSGNUM I ( 4,0 ) NOT NULL && ID mesaj (cheie candidat)

MSGTYP C ( 1,0 ) NOT NULL && Tipul de afișare este necesar

MSGTIT C ( 60,0 ) NOT NULL && Titlu pentru MessageBox, Text pentru Fereastra/Stare de așteptare

MSGBTN N ( 1,0 ) NOT NULL Butonul && de setat ca implicit (numai pentru MessageBox)

MSGTXT M ( 4,0 ) NOT NULL && Textul mesajului (Numai pentru Mesaje)

O singură cheie (candidată) este definită în câmpul MsgNum pentru a oferi o capacitate de căutare rapidă după numărul mesajului. Rețineți că am folosit un câmp de memorare pentru stocarea textului actual al mesajului, astfel încât atât textul, cât și aspectul fiecărui mesaj să poată fi predefinite.

Am definit un număr limitat de tipuri de mesaje standard, pe care le folosim pentru a predefini modul în care este afișat efectiv un mesaj, după cum urmează:

Tabelul 10.5 Definiții standard ale tipului de mesaj

Cod 	TypeStyleDisplay Type
E 	Pictogramă DialogStop Eroare cu numai butonul „OK” implicit16
W 	Dialog de avertizare Pictogramă Exclamație cu butoanele „OK” și „Anulare”49
	Dialog de informații Pictogramă de informații doar cu butonul implicit „OK”64
C 	Dialog de confirmare Pictogramă Întrebare cu butoanele „Da” și „Nu”36
X 	Centered Window Fereastra Wait, centrată pe ecran99
Y 	Fereastra implicită WindowWait, colțul din dreapta sus al ecranului98
			

Z 	Setează textul în bara de stare implicită97

Clasa de gestionare a mesajelor (msgmgr.prg)

Această clasă, ca și clasa Error Logging descrisă în secțiunea anterioară, se bazează pe un FormSet, astfel încât poate avea propria sa Private DataSession. Clasa este configurată astfel încât să fie instanțiată o singură dată ca parte a pornirii aplicației. Metoda sa Init stochează propria sa sesiune de date într-o proprietate protejată și setează tabelul de mesaje în acea sesiune de date (ceea ce ajută la asigurarea faptului că tabelul de mesaje nu este închis din greșeală de acțiunile altor obiecte):

**************************************************** ********************

* 	Program.MsgMgr.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Definiție de clasă pentru gestionarea mesajelor

**************************************************** ********************

DEFINEȚI CLASA xMs^gr CA FORMSET

PROTEJAT FormCount, Vizibil, DataSession, nDSId

FormCount = 0 && Nu permiteți niciun formular

Vizibil = .F. && Păstrați setul de forme invizibil

DataSession = 2 && Într-o sesiune de date privată

nDSId = 1 && DS implicit la 1

PROCEDURA Init

Cu asta

*** Deschide tabelul cu mesaje

DACĂ ! USED('msgtable')

USE msgtable IN 0 AGAIN SHARED ALIAS msgtable

ENDIF

*** Salvați sesiunea de date a manipulatorului de mesaje

.nDSId = .DataSessionID

SE TERMINA CU

ENDPROC

Clasa are, de asemenea, o singură metodă personalizată expusă (ShoMsg) care se așteaptă să primească numărul ID al unui mesaj din tabelul de mesaje standard ca parametru. După ce a verificat dacă parametrul este numeric, această metodă salvează sesiunea de date curentă și se modifică în sesiunea de date privată a handler-ului de mesaje:

PROCEDURA ShoMsg(tnMsgNum)

LOCAL lnOrigDS, lnRetVal

Cu asta

*** Numărul mesajului trebuie să fie numeric

IF VARTYPE (tnMsgNum) # "N"

EROARE „9000: Un parametru numeric valid trebuie să fie transmis către ShoMsg()”

*** Indicator de eroare de returnare

RETURN -1

ENDIF

*** Comutați la Mesaje Handler DS

InOrigDS = SET(„DATASESSION”)

SETĂ SESIUNEA DE DATE LA (.nDSId )

*** Găsiți detaliile mesajului obligatoriu

IF SEEK(tnMsgNum, 'msgtable', 'msgnum' )

*** Apelați Handler-ul adecvat pentru acest mesaj în funcție de tip

lnRetVal = .GetMsgS tyle()

ALTE

*** Numărul mesajului nu este valid

EROARE „9000: Numărul mesajului „ + ALLTRIM(STR(tnMsgNum )) + „ Nerecunoscut”

*** Indicator de eroare de returnare

lnRetVal = 0

ENDIF

*** Restaurați DS original și returnați

SETĂ SESIUNEA DE DATE LA (lnOrigDS)

RETURN lnRetVal

SE TERMINA CU

ENDPROC

Dacă numărul mesajului transmis nu este găsit, handlerul returnează pur și simplu un cod de eroare (0), în caz contrar, indicatorul de înregistrare este lăsat îndreptat către mesajul corect și metoda personalizată GetMsgStyle protejată este apelată pentru a transmite afișarea efectivă a mesajului către metoda corecta, dupa cum urmeaza:

**************************************************** *****************

*** MsgMgr::GetMsgStyle() - Verificați tipul mesajului și apelați handlerul corespunzător

**************************************************** *****************

PROCEDURĂ PROTEJATĂ GetMsgStyle

*** Verificați tipul de mesaj curent și apelați handlerul corect cu

*** orice parametri necesari

LOCAL lcMsgTyp, lnRetVal

lcMsgTyp = msgtable.msgtyp

FACE CAZ

CASE lcMsgTyp = „E”

*** Eroare standard = butonul „STOP” + „OK”.

lnRetVal = .DoMsgBox( 16 )

CASE lcMsgTyp = „W”

*** Avertisment standard = butonul „EXCLAMAȚIE” + „OK/Anulare”.

lnRetVal = .DoMsgBox( 49 )

CASE lcMsgTyp = „I”

*** Informații standard = „INFO” + butonul OK

lnRetVal = .DoMsgBox( 64 )

CASE lcMsgTyp = „C”

*** Confirmare standard = „ÎNTREBARE” + Opțiuni Da/Nu

lnRetVal = .DoMsgBox( 36 )

CASE lcMsgTyp = „X”

*** Așteptați fereastra centrată pe ecran

lnRetVal = .DoWait(.T.)

CASE lcMsgTyp = „Y”

*** Fereastra de așteptare din dreapta sus

lnRetVal

.DoWait()

CAZ IcMsgTyp = „Z”

*** Mesaj din bara de stare

lnRetVal = .DoS tat()

IN CAZ CONTRAR

*** Nu este necesară afișarea - Returnare succes

lnRetVal = 1

ENDCASE

*** Returnați tipul de afișare

RETURN lnRetVal

ENDPROC

Afișările reale ale mesajelor sunt, cu excepția calculării poziției pentru „așteptare” centrată

fereastra,' destul de simplu:

**************************************************** *****************

*** MsgMgr::DoMsgBox(tnParam) - Apelați caseta de mesaje pentru a afișa mesajul

*** Butonul de întoarcere folosit pentru a închide caseta de mesaje

**************************************************** *****************

PROCEDURĂ PROTEJATĂ DoMsgBox (tnParam)

LOCAL lnRetVal, lcTxt, lcTit

*** Obțineți mesajul și titlul din tabel

lcTxt = ALLTRIM( msgtable.msgtxt )

lcTit = ALLTRIM( msgtable.msgtit )

*** Setați butonul implicit - Stocați în tabel ca 1, 2 sau 3

DACĂ ! EMPTY(msgtable.msgbtn)

lnParam = tnParam + ((msgtable.msgbtn - 1) * 256)

ALTE

lnParam = tnParam

ENDIF

lnRetVal = MESSAGEBOX( lcTxt, lnParam, lcTit )

RETURN lnRetVal

ENDPROC

**************************************************** *****************

*** MsgMgr::DoWait(tlCenter) - Afișează mesajul din fereastra de așteptare

*** Fără valoare de returnare specifică

**************************************************** *****************

PROCEDURĂ PROTEJATĂ DoWait(tlCenter)

lcTxt LOCAL

*** Obțineți mesaj de la masă

lcTxt = ALLTRIM( msgtable.msgtit )

IF tlCenter

LOCAL lnTexLen, lnRows, lnAvgChar, lcDispText, lnCnt, lcLine, lnCol, lnRow

*** Calculați dimensiunea mesajului

SETĂ MEMOWIDTH LA 80

_MLINE = 0

lnTexLen = 0

lnRows = MEMLINES(lcTxt)

*** Calculați dimensiunea textului pentru poziționare

InAvgChar = FONTMETRIC( 6, 'Arial', 8) / ;

FONTMETRIC( 6, _SCREEN.FontName, _SCREEN.FontSize )

lcDispText = ''

*** Găsiți cel mai lung rând de text din mesaj

FOR lnCnt = 1 TO lnRows

lcLine = ' ' + MLINE( lcTxt, 1, _MLINE) + ' '

lcDispText = IIF(! EMPTY( lcDispText ), CHR(13), "") + lcDispText + lcLine

lnTexLen = MAX( TXTWIDTH(lcLine,'MS Sans Serif',8,'B')+4, lnTexLen) && 4 este chenar

URMĂTORUL

*** Pregătiți poziția pentru fereastră pe baza celui mai lung rând

lnCol = INT((SCOLS() - lnTexLen * lnAvgChar )/2)

lnRow = INT((SROWS() - lnRows)/2)

*** Afișează fereastra centrată

Așteptați fereastra lcDispText LA lnRow, lnCol ACUM

ALTE

*** Fereastra de așteptare simplă sus/dreapta

ASTEPTATI FEREASTRA lcTxt ACUM ASTEPTATI

ENDIF

*** Returnează „Succes”

RETURNARE 1

ENDPROC

**************************************************** *****************

*** MsgMgr::DoStat() - Afișează mesajul din bara de stare

*** Fără valoare de returnare specifică

**************************************************** *****************

PROCEDURĂ PROTEJATĂ DoStat()

lcTxt LOCAL

*** Obțineți mesaj de la masă

lcTxt = ALLTRIM( msgtable.msgtit )

SETĂ MESAJUL LA lcTxt

*** Returnează „Succes”

RETURNARE 1

ENDPROC

Folosind manipulatorul de mesaje

Odată ce obiectul de gestionare a mesajelor este creat, tot ceea ce este necesar pentru a afișa un mesaj este să apelați metoda ShoMsg și să transmiteți numărul mesajului necesar. Exemplul de cod pentru acest capitol include un tabel de mesaje care definește câte unul din fiecare tip de mesaj. Pentru a testa handlerul, pur și simplu creați obiectul și apelați un mesaj:

goMsgMgr = NEWOBJECT('xMsgMgr', 'msgmgr.prg', NULL)

lnChoice = goMsgMgr.ShoMsg(1030)

Managerul de mesaje va returna întotdeauna codul de identificare pentru butonul apăsat pentru a închide o casetă de mesaj sau un „1” numeric pentru toate celelalte mesaje afișate.
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Concluzie

Sperăm că exemplele din acest capitol v-au oferit câteva idei utile și suntem siguri că vă veți putea gândi la multe alte moduri de a folosi puterea și flexibilitatea orelor non-vizuale.
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Capitolul 11 - Forme și alte clase vizuale

„Forma și funcția sunt o unitate, două fețe ale unei monede. Pentru a îmbunătăți funcția, trebuie să existe sau să fie creată o formă adecvată.” ("Rofing: The Integration ofHuman Structions", de Ida P. Rolf).

Aplicația dvs. poate implementa o logică care este mai complexă decât știința rachetei, dar dacă interfața este neplăcută de utilizator, nimănui nu va ști și nu va interesa. Cel mai important lucru pentru persoanele care vor folosi aplicația dvs. este dacă le face sau nu munca mai ușor de realizat. Software-ul care provoacă mai multă muncă sau care îngreunează viața profesională a cuiva este un software prost, indiferent de modul în care îl tăiați. În acest capitol, vă vom împărtăși câteva cursuri care nu numai că vor face viața mai ușoară pentru utilizatorii dvs. finali, dar vă vor face viața mai ușoară pe măsură ce o dezvoltați.
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Cum fac ca formularele mele să umple întregul ecran, indiferent de rezoluția ecranului? (Exemplu: CH11.VCX::FrmMaximize și

Maximize.scx)

Dacă aplicația pe care o construiți este suverană (adică o aplicație destinată să fie utilizată exclusiv de un utilizator, spre deosebire de simpla partajare a unei părți a ecranului utilizatorului cu alte aplicații), probabil că veți dori ca formularele să se maximizeze atunci când sunt instanțiate, indiferent de rezoluția ecranului pe care a setat-o un anumit utilizator.

Pentru a face acest lucru, va trebui să calculați raportul prin care rezoluția actuală a ecranului diferă de standardul (care oricum ar trebui să fie întotdeauna 640 x 480!) pentru care sunt concepute formularele dvs. Acest raport poate fi apoi aplicat tuturor formelor și controalelor acestora pentru a redimensiona totul fără a schimba proporțiile relative. Acest lucru se realizează cel mai bine adăugând o metodă ResizeControls la clasa formularului și apelând-o din metoda Init a formularului, după ce mai întâi redimensionăm formularul în sine, astfel:

LOCAL loControl

CU Thisform

*** Determinați raportul necesar pentru a maximiza forma

*** în funcție de rezoluția ecranului și stocați-l pentru a forma proprietăți

.WidthRatio = SISTEMRIC( 1 ) / 640

.Raport înălțime = SISTEMRIC( 2 ) / 480

*** Dacă rezoluția este mai mare de 640 x 480, repoziționați

*** și maximizați forma

DACĂ .WidthRatio > 1

.Sus = 0

.Stânga = 0

.Width = .Width * .WidthRatio

.Inaltime = .Inaltime * .Raport de inaltime

*** Și redimensionați fiecare control conținut în formular

PENTRU FIECARE loControl IN .Controale

.ResizeControls( loControl )

ENDFOR

ENDIF

SE TERMINA CU

Rețineți că folosim funcția nativă SysMetric() pentru a determina rezoluția curentă a ecranului și apoi pentru a calcula atât rapoartele orizontale, cât și cele verticale. Aceste rapoarte sunt salvate ca proprietăți de formular și utilizate imediat pentru a redimensiona formularul în sine. Apoi parcurgem fiecare dintre obiectele din colecția Controls a formularului, apelând metoda ResizeControls și trecând o referință de obiect controlului pentru fiecare.

Metoda ResizeControls trebuie să întreprindă acțiuni diferite în funcție de faptul dacă obiectul pe care îl primește este un control simplu sau un alt container cu mai multe controale. Pentru a gestiona această situație, metoda trebuie să fie capabilă să detalieze în containere denumindu-se recursiv. Prima sarcină, totuși, este să setați proprietățile Sus, Stânga, Înălțime și Lățime pentru controlul trecut dacă are aceste

proprietăți. (Primul tău gând ar putea fi că cu siguranță toate comenzile vizuale au aceste proprietăți? Nu așa, Pageframes, de exemplu, nu au de fapt înălțime și lățime, ci au proprietăți PageHeight și PageWidth.)

LPARAMETERS toControl

LOCAL loPage, loControl, loColumn, lnColumnWidths[1], lnCol

DACĂ PEMSTATUS(la control, „Lățime”, 5)

toControl.Width = toControl.Width * Thisform.WidthRatio

ENDIF

IF PEMSTATUS(la control, „Înălțime”, 5)

toControl.Height = toControl.Height * Thisform.HeightRatio

ENDIF

IF PEMSTATUS(la control, „Sus”, 5)

toControl.Top = toControl.Top * Thisform.HeightRatio

ENDIF

IF PEMSTATUS(la control, „Stânga”, 5)

toControl.Left = toControl.Left * Thisform.HeightRatio

ENDIF

Apoi, trebuie să redimensionăm fontul pentru controlul curent. Dacă se întâmplă să fie o grilă, este un caz special și trebuie tratat separat, deoarece schimbarea fontului unei grile resetează lățimile coloanei grilei. Înainte de a modifica o grilă, trebuie să salvăm toate lățimile coloanelor, astfel încât să le putem restabili ulterior:

IF UPPER( ALLTRIM( toControl.Baseclass ) ) = 'GRAD'

DIMENSIUNE lnColumnWidths[toControl.ColumnCount]

FOR lnCol = 1 TO toControl.ColumnCount

lnColumnWidths[lnCol] = toControl.Columns[lnCol].Width

ENDFOR

toControl.Fontsize = INT( toControl.FontSize * Thisform.WidthRatio )

FOR lnCol = 1 TO toControl.ColumnCount

toControl.Columns[lnCol].Width = lnColumnWidths[lnCol]

ENDFOR

ALTE

IF PEMSTATUS(la Control, 'Fontsize', 5 )

toControl.Fontsize = INT( toControl.FontSize * Thisform.WidthRatio )

ENDIF

ENDIF

În continuare, trebuie să stabilim dacă avem un obiect care conține alte obiecte. Când acesta este cazul, trebuie să apelăm recursiv metoda ResizeControls și să îi transmitem o referință la fiecare dintre obiectele conținute. Următorul cod face acest lucru atunci când obiectul curent este un cadru de pagină, o pagină, un container, un grup de comandă sau un grup de opțiuni.

FACE CAZ

CASE UPPER( toControl.BaseClass ) = 'PAGEFRAME'

PENTRU FIECARE LOPAGE IN toControl.Pages

Thisform.ResizeControls( loPage )

ENDFOR

CASE INLIST( UPPER( toControl.BaseClass ), „PAGE”, „CONTAINER” )

PENTRU FIECARE loControl IN toControl.Controls

Thisform.ResizeControls( loControl )

ENDFOR

CASE INLIST( UPPER( ALLTRIM( laControl.BaseClass ) ), ;

„COMMANDGROUP”, „OPTIONGROUP” )

LnButton LOCAL

FOR lnButton = 1 TO toControl.ButtonCount

ThisForm.resizeControls( toControl.Buttons[lnButton] ) ENDFOR

În cele din urmă, trebuie să ne ocupăm de cazurile speciale. Dacă obiectul curent este o grilă, trebuie să setăm proprietățile sale RowHeight și HeaderHeight. De asemenea, trebuie să iterăm prin colecția de coloane și să setăm Lățimea fiecărei coloane conținute în grilă:

CASE UPPER( toControl.BaseClass ) = 'GRID'

CU toControl

.RowHeight = .RowHeight * Thisform.HeightRatio

.HeaderHeight = .HeaderHeight * Thisform.HeightRatio

PENTRU FIECARE loColumn IN .Columns

loColumn.Width = loColumn.Width * Thisform.WidthRatio

ENDFOR

SE TERMINA CU

Dar dacă obiectul curent este fie o casetă combo sau listă, trebuie să-l recalculăm și să-l resetam

ColumnWidths:

CASE INLIST( UPPER( toControl.BaseClass ), 'COMBOBOX', 'LISTBOX' )

LOCAL lnCol, lnStart, lnEnd, lnLen, lcColumnWidths

CU toControl

DACĂ .ColumnCount < 2

.ColumnWidths = ALLTRIM( STR( .Width ) )

ALTE

lcColumnWidths = ''

lnStart = 1

FOR lnCol = 1 TO .ColumnCount - 1

lnEnd = AT(

.ColumnWidths

lnCol)

lnLen

la sfârşit

lnStart

lcColumnWidths

lcColumnWidths + ;

)

) + ;

IIF( EMPTY( lcColumnWidths

ALLTRIM( STR( VAL (SUBSTR(

.ColumnWidths, lnStart, lnLen ) ) ;

* Thisform.WidthRatio ) )

lnStart

lnEnd + 1

ENDFOR

lnLen = LEN( .ColumnWidths

lnStart + 1

)

lcColumnWidths

lcColumnWidths +

+ ;

ALLTRIM( STR( VAL (SUBSTR( .ColumnWidths, lnStart, lnLen ) ) );

* Thisform.WidthRatio ) )

.ColumnWidths = lcColumnWidths

ENDIF

SE TERMINA CU

IN CAZ CONTRAR

*** Nu există altfel... Cred că avem toate cazurile

ENDCASE
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Cum creez formulare redimensionabile? (Exemplu: CH11. VCX::cusResizer și

Resize.scx)

Clasa de forme de auto-maximizare discutată mai sus este un caz special al unei forme redimensionabile, prin aceea că este o operație o singură dată, dar principiile de bază sunt aceleași. De fiecare dată când formularul este redimensionat, trebuie să calculăm raportul cu care înălțimea și lățimea formularului s-au schimbat în raport cu dimensiunile sale originale și apoi să aplicăm acel raport fiecărui control de pe formular pentru a păstra aceeași dimensiune și poziție relativă în orice moment.

Figura 11.1 Formă redimensionabilă - așa cum este instanțiată cu dimensiunile originale

Cel mai bun mod de a gestiona acest lucru este să creați o clasă care va face calculele necesare și pur și simplu să o adăugați la fiecare formular care trebuie să fie redimensionat. Clasele de bază care sunt livrate cu Visual FoxPro versiunea 6.0 includ de fapt o astfel de clasă de redimensionare. Cu toate acestea, deși poate fi adecvat pentru formulare simple, cu câteva controale de bază, este destul de limitat și nu gestionează corect controale mai complexe, cum ar fi grile, combo-uri sau casete cu listă. Nici măcar nu încearcă să redimensioneze sau să repoziționeze OptionGroups sau CommandGroups. Drept urmare, în opinia noastră, nu merită prea multă atenție.

Figura 11.2 Forma redimensionabilă - făcută mai mică

Pentru a oferi flexibilitate maximă, am creat un. Clasa de redimensionare care va face față corect tuturor acestor cerințe. Obiectul bazat pe această clasă trebuie adăugat la formularul sau clasa de formular în metoda sa Init, deoarece trebuie să salveze dimensiunile originale ale tuturor controalelor de formular atunci când este instanțiat. În mod clar, trebuie să ne asigurăm că toate controalele formularului au fost instanțiate înainte ca metoda Init a redimensionatorului să ruleze, așa că folosim cod ca acesta în metoda Init a formularului:

DACA DODEFAUbTO

This.AddObject('Resizer', 'cusResizer' )

ENDIF

După cum sa menționat mai sus, cheia pentru a face proprietatea funcției de clasă este mai întâi să salvați toate proprietățile de orientare vizuală relevante pentru fiecare obiect de pe formular. În Visual FoxPro 6.0, putem folosi metoda AddProperty a fiecărui control de formular pentru a salva aceste informații în obiectul însuși. Astfel, atunci când obiectul de redimensionare este instanțiat, metoda sa SaveOriginalDimensions procesează colecția Controls a formularului, exploatând în toate containerele (similar cu clasa frmMaximize prezentată mai sus). Această metodă creează proprietățile necesare pentru a salva Height, Width, PageHeight, ColumnWidths și așa mai departe. Evident, clasa de bază a obiectelor determină ce proprietăți sunt adăugate prin AddProperty. Acest cod, în metoda Init a redimensionatorului, invocă metoda personalizată SaveOriginalDimensions astfel:

LOCAL loControl

CU Thisform

*** Salvați dimensiunile formularului la instanțiere

.AddProperty( 'nOriginalHeight', .Height )

.AddProperty( 'nOriginalWidth', .Width )

*** Setați o lățime și o înălțime minime pentru a evita erorile mai târziu

.MinWidth = .Width / 2

.MinHeight = .Height / 2

*** Acum salvați proprietățile vizuale relevante (înălțime, lățime, lățime coloane etc.)

*** din toate controalele din formular

PENTRU FIECARE loControl IN .Controale

This.SaveOriginalDimensions( loControl )

ENDFOR

SE TERMINA CU

SaveOriginalDimensions analizează toate containerele, adăugând proprietățile necesare și inițialându-le cu valorile corecte pe măsură ce se rotește prin colecția de controale a formularului:

LPARAMETERS toControl

LOCAL loPage, loControl, loColumn, lnCol

Evident, dacă obiectul nu are o metodă AddProperty, nu o putem folosi pentru a adăuga proprietățile necesare pentru a salva dimensiunile originale. Dacă acesta este cazul, vom salva. Acest lucru poate provoca unele anomalii mai târziu, când formularul este redimensionat, dar este cu siguranță de preferat să existe o eroare fatală:

DACĂ ! PEMSTATUS(la control, „Adăugați proprietate”, 5)

ÎNTOARCERE

ENDIF

Apoi verificăm proprietățile obișnuite: Înălțime, Lățime, Sus și Stânga. Dacă sunt proprietăți valide pentru obiectul curent, adăugăm proprietățile necesare obiectului și salvăm dimensiunile sale originale:

DACĂ PEMSTATUS(la control, „Lățime”, 5)

toControl.AddProperty( 'nOriginalWidth', toControl.Width )

ENDIF

IF PEMSTATUS(la control, „Înălțime”, 5)

toControl.AddProperty('nOriginalHeight', toControl.Height )

ENDIF

IF PEMSTATUS(la control, „Sus”, 5)

toControl.AddProperty( 'nOriginalTop', toControl.Top )

ENDIF

IF PEMSTATUS(la control, „Stânga”, 5)

laControl.AddProperty('nOriginalLeft', toControl.Left )

ENDIF

IF PEMSTATUS(la Control, 'Fontsize', 5 )

toControl.AddProperty( 'nOriginalFontSize', toControl.FontSize )

ENDIF

Apoi verificăm dacă obiectul curent este un container. Dacă este și conține alte obiecte, va trebui să le trecem recursiv acestei metode:

FACE CAZ

CASE UPPER( toControl.BaseClass ) = 'PAGEFRAME'

PENTRU FIECARE LOPAGE IN toControl.Pages

This.SaveOriginalDimensions( loPage )

ENDFOR

CASE INLIST( UPPER( toControl.BaseClass ), „PAGE”, „CONTAINER” )

PENTRU FIECARE loControl IN toControl.Controls

This.SaveOriginalDimensions( loControl )

ENDFOR

CASE INLIST( UPPER( ALLTRIM( laControl.BaseClass ) ), 'COMMANDGROUP', 'OPTIONGROUP' )

LnButton LOCAL

FOR lnButton = 1 TO toControl.ButtonCount

This.SaveOriginalDimensions(toControl.Buttons[lnButton] )

ENDFOR

Ne putem ocupa și de cazurile speciale aici. De exemplu, grilele au proprietăți RowHeight și HeaderHeight care trebuie salvate și trebuie să salvăm lățimile originale ale tuturor coloanelor conținute. Casetele Combo și Listă necesită, de asemenea, o manipulare specială pentru a salva ColumnWidths originale:

CASE UPPER( toControl.BaseClass ) = 'GRID'

CU toControl

.AddProperty( 'nOriginalRowHeight', .RowHeight )

.AddProperty( 'nOriginalHeaderHeight', .HeaderHeight )

.AddProperty( 'nOriginalColumnWidths[1]' )

DIMENSIUNE .nOriginalColumnWidths[ .ColumnCount ]

FOR lnCol = 1 TO .ColumnCount

.nOriginalColumnWidths[lnCol] = .Columns[lnCol].Width

ENDFOR

SE TERMINA CU

CASE INLIST( UPPER( toControl.BaseClass ), 'COMBOBOX', 'LISTBOX' )

CU toControl

.AddProperty( 'nOriginalColumnWidths', .ColumnWidths )

SE TERMINA CU

IN CAZ CONTRAR

*** Nu există altfel... Cred că avem toate cazurile

ENDCASE

După ce am salvat toate valorile originale, trebuie să ne asigurăm că redimensionarea este invocată ori de câte ori formularul este redimensionat. O singură linie de cod în metoda Resize a formularului este tot ceea ce este necesar:

Thisform.cusResizer.AdjustControls()

Metoda personalizată AdjustControls parcurge colecția de controale a formularului în același mod ca metoda SaveOriginalDimensions. În acest caz, totuși, metoda invocă metoda ResizeControls pentru a redimensiona și a repoziționa controalele folosind lățimea curentă a formularului împărțită la lățimea inițială ca factor prin care controalele conținute sunt făcute mai largi sau mai înguste.

Exemplul de formular Resize.SCX arată cum poate fi utilizată clasa pentru a gestiona redimensionarea unui formular destul de complex. Cu toate acestea, un cuvânt de precauție este necesar aici. Această clasă nu va face față obiectelor care sunt adăugate în timpul execuției folosind instanțierea întârziată. Acest lucru se datorează faptului că configurarea presupune că toate obiectele există înainte ca redimensionarea în sine să fie instanțiată. Dacă trebuie să utilizați instanțierea întârziată într-o formă redimensionabilă, apelați metoda SaveOriginalDimensions a redimensionatorului în mod explicit cu o referință la obiectul nou adăugat și apoi invocați imediat metoda ResizeControls.

Anumite alte clase pe care le-am introdus mai devreme în această carte ar necesita, de asemenea, modificări pentru a funcționa corect într-o formă redimensionabilă. De exemplu, atunci când este utilizată într-o formă redimensionabilă, caseta de editare extinsă introdusă în Capitolul 4 necesită apelarea metodei SaveOriginalDimensions de fiecare dată când este extinsă. Deoarece dimensiunea și poziția sa se schimbă ori de câte ori formularul este redimensionat, nu este suficient să stocați aceste informații o dată când caseta de editare este instanțiată.

Copyright 2000 de către Marcia Akins, Andy Kramek și Rick Schummer Toate drepturile rezervate

Cum caut anumite înregistrări? (Exemplu: SearchDemo.scx

și Srch.scx)

Abilitatea de a găsi o înregistrare specifică pe baza unui fel de criteriu de căutare este o cerință foarte comună. Am creat un formular generic „pop-up” (Srch.scx) care poate fi folosit pentru a căuta o potrivire pe orice câmp dintr-un tabel dat. Trebuie doar să vă asigurați că orice formă care o calizează, face acest lucru cu următorii parametri în ordinea în care sunt listați.

Tabelul 11.1 Parametrii trecuți în formularul de căutare

Nume parametru 	Descriere parametru
ToParent 	la formularul de apelare
TcAlias 	Alias în care se efectuează căutarea
TcField 	Câmp în care să căutați o potrivire
TcAction 	Acțiune de luat atunci când este găsită o potrivire

Exemplu de căutare generică	
	

Căutare în Grid 	Căutare câmp

Anterior I 	Următorul ISSearch |Exit I
			

formularul de căutare în acțiune

Figura 11.3 Generic

Fiecare obiect din formularul de apelare trebuie să fie capabil să se înregistreze cu acest formular ca obiect curent. Acest lucru este necesar deoarece atunci când utilizatorul face clic pe butonul „căutare”, butonul devine controlul ActiveC al formularului. Cu toate acestea, dorim să căutăm în câmpul legat de controlul care a fost ActiveControl înainte de a face clic pe butonul de căutare, așa că avem nevoie de o modalitate de a-l identifica. Tot ce avem nevoie pentru a realiza această funcționalitate este o proprietate personalizată de formular numită оActiveControl și următorul cod în metoda LostFocus a controalelor noastre conștiente de date:

IF PEMSTATUS ( Thisform, OActiveControl ' , 5 )

Acest formular. oActiveControl = Aceasta

ENDIF

Formularul de căutare este instanțiat cu acest cod în metoda de căutare personalizată a formularului de apelare. Observați că formularul de căutare este instanțiat doar dacă formularul de apelare nu are o referință la unul care există deja:

*** Vedeți mai întâi dacă avem deja un formular de căutare disponibil

IF VARTYPE( Thisform.oChild ) = 'O'

*** Dacă avem unul, trebuie doar să setați câmpul să caute

Thisform.oChild.cField = JUSTEXT( This.oActiveControl.ControlSource )

Acest formular. oChild.Activate()

ALTE

DO FORM Srch WITH This, This.cPrimaryTable, ;

JUSTEXT( This.oActiveControl.ControlSource ), ;

„This.oParent.oActiveControl.SetFocus()”

ENDIF

*** Acest lucru funcționează deoarece toate controalele la care se face referire în cod

*** au un prefix cu trei caractere care definesc ceea ce sunt (de exemplu, txt)

*** urmat de un nume descriptiv

Thisform.oChild.Caption = 'Căutați ' + SUBSTR( This.oActiveControl.Name, 4 )

Formularul de căutare salvează parametrii pe care îi primește în proprietăți personalizate ale formularului, astfel încât să fie disponibili pentru întregul formular. De asemenea, trimite o referință la sine înapoi la formularul de apelare, astfel încât formularul de apelare să poată elibera formularul de căutare (dacă acesta încă există) atunci când este eliberat:

LPARAMETERS toParent, tcAlias, tcField, tcAction

IF DODEFAULT( toParent, tcAlias, tcField, tcAction )

CU Thisform

*** Salvați referința la formularul care a început căutarea

.oParent = toParent

*** De asemenea, salvați tabelul pentru a căuta și numele câmpului pentru a căuta

.cAlias = tcAlias

.cField = tcField

*** În cele din urmă, salvați acțiunea de efectuat atunci când este găsită o potrivire

.cAction = tcAction

*** Salvați numărul de înregistrare curent

.nRecNo = RECNO( .cAlias )

*** Dați formularului părinte o referință la formularul de căutare

*** Deci, când închidem formularul părinte, închidem și formularul de căutare

.oParent.oChild = Aceasta

SE TERMINA CU

ENDIF

Formularul de căutare are trei metode personalizate, câte una pentru fiecare dintre butoanele de comandă. Metoda Find caută prima potrivire din câmpul specificat cu valoarea introdusă în caseta text astfel:

LOCAL lnSelect, lcField, luValue, lcAction

*** Salvați zona de lucru curentă

lnSelect = SELECT ()

CU ThisForm

Dacă câmpul conține date de caractere, dorim să forțăm valoarea din caseta de text la majuscule. Acest lucru este ușor de realizat prin plasarea unui ! în proprietatea sa format în foaia de proprietăți. Prin urmare, nu este nevoie să efectuați această sarcină în cod:

luValue = IIF( VARTYPE( .txtSearchString.Value ) = 'C', ;

ALLTRIM( .txtSearchString.Value ), .txtSearchString.Value )

SELECTAȚI ( .cAlias )

Apoi verificăm o etichetă index în câmpul specificat folosind funcția noastră utilă IsTag(). Dacă avem o etichetă, vom folosi căutare pentru a găsi o potrivire. În caz contrar, trebuie să folosim locate:

IF IsTag( .cField )

SEEK luValue COMANDA TAG ( .cField ) IN ( .cAlias )

ALTE

lcField = .cField

IF VARTYPE( EVAL( .cAlias + '.' + lcField ) ) = 'C'

LOCATE FOR UPPER( &lcField ) = luValue

ALTE

LOCATE FOR &lcField = luValue

ENDIF

ENDIF

Dacă se găsește o potrivire, efectuăm următoarea acțiune care a fost transmisă metodei Init a formularului și salvăm numărul de înregistrare al înregistrării curente. În caz contrar, afișăm un mesaj pentru a anunța utilizatorul că nu a fost găsită nicio potrivire și restabilim indicatorul de înregistrare acolo unde era înainte de a începe căutarea:

*** Dacă a fost găsită o potrivire, efectuați următoarea acțiune

DACA ESTE GASIT ()

*** Salvați numărul de înregistrare al înregistrării potrivite

.nRecNo = RECNO( .cAlias )

SELECTARE ( lnSelect )

lcAction = .cAction

&lcAcţiune

ALTE

FEREASTRA DE Așteptați „Nu s-a găsit nicio potrivire!” NU AȘTEPTAȚI

*** Restaurează indicatorul de înregistrare

GOTO .nRecNo IN (.cAlias )

SELECTARE ( lnSelect )

ENDIF

SE TERMINA CU

Codul din metoda FindNext este foarte asemănător cu codul din metoda Find. Din păcate, trebuie să folosim locate în metoda FindNext deoarece seek găsește întotdeauna prima potrivire și începe întotdeauna din partea de sus a fișierului. Acesta este codul care găsește următoarea înregistrare, dacă există una:

*** Dacă ne aflăm la ultima înregistrare găsită, treceți la următoarea înregistrare

OCOLIRE

*** Trebuie să utilizați LOCATE pentru a găsi următorul, deoarece căutarea începe întotdeauna

*** în partea de sus și găsește primul meci

lcField = .cField

luValue = IIF( VARTYPE( .txtSearchString.Value ) = 'C', ;

ALLTRIM( .txtSearchString.Value ), .txtSearchString.Value )

IF VARTYPE( EVAL( .cAlias + '.' + lcField ) ) = 'C'

LOCATE FOR UPPER( &lcField ) = luValue REST

ALTE

LOCATE FOR &lcField = luValue REST

ENDIF

Codul din metoda personalizată Anulare a formularului de căutare anulează căutarea, repoziționează indicatorul de înregistrare și închide formularul de căutare astfel:

CU Thisform

GOTO .nRecNo IN ( .cAlias )

.Eliberare()

SE TERMINA CU

Unele dintre cele mai importante coduri rezidă în metoda Destroy a fiecărei forme. Dacă formularul de căutare nu avea acest cod în metoda Destroy:

IF TYPE („Thisform.oParent.Name”)

„C”

Thisform.oParent.oChild = .NULL.

ENDIF

ar refuza să dispară atunci când utilizatorul ar face clic pe butonul de anulare, deoarece formularul care l-a numit ar fi în continuare indicat către el. În acest caz, referința deținută de formularul de apelare este cunoscută ca referință suspendată. Referința pe care o are formularul de căutare la formularul de apelare (This.oParent) se curăță automat după sine, deci este mai puțin supărătoare. Când formularul de căutare este eliberat, este eliberată și referința pe care o deține la formularul de apelare. Acest cod din metoda Destroy a formularului de apelare se asigură că atunci când moare, ia cu el formularul de căutare:

*** Eliberați formularul de căutare dacă este încă deschis

IF VARTYPE( Thisform.oChild ) # 'X'

Thisform.oChild.Release()

ENDIF
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Cum construiesc SQL din mers? (Exemplu: FilterDemo.scx și

BuildFilter.scx)

Sunt disponibile multe instrumente terțe excelente și oferă această funcționalitate, precum și capacitatea de a crea, modifica și tipări rapoarte prin rezultatul SQL generat de utilizator. Nu este intenția noastră să reinventăm roata aici. Dacă cerințele aplicației dvs. pentru SQL generat de utilizatorul final sunt complexe, în mod clar soluția este una dintre aceste produse foarte bune. Acestea fiind spuse, există ocazii în care este necesar să se prezinte utilizatorului final un mijloc de a construi o condiție de filtrare foarte simplă care poate fi aplicată unui singur tabel. În acest caz, instrumentul terță parte poate oferi mult mai multe funcționalități decât aveți nevoie. BuildFilter.scx este un simplu generator de filtre și este furnizat împreună cu exemplul de cod pentru acest capitol. Acesta creează condiția de filtru pentru un singur alias. Cu modificări ușoare și adăugarea unui cadru de pagină, acest formular poate fi ușor modificat pentru a uni două tabele (sau mai multe) înainte de a construi filtrul.

Figura 11.4 Forma generică pentru a construi condiția de filtru

Cali BuildFilter.scx folosind această sintaxă:

FORMATĂ BUILDFILTER CU „<ALIAS>” ÎN IcSQLString

Apoi puteți utiliza condiția de filtru returnată pentru a rula o interogare SQL ca aceasta:

SELECTAȚI * FROM <alias> WHERE &lcSQLstring ÎN CURSOR Terrp NOFILTER

sau pentru a seta un filtru pe aliasul specificat, astfel:

SELECTAȚI <alias>

SETĂ FILTRUL LA (IcSQLstring)

Formularul BuildFilter se așteaptă să primească un alias de tabel ca parametru și îl stochează în proprietatea personalizată cAlias pentru a-l face disponibil întregului formular. Metoda personalizată SetForm este apoi invocată pentru a popula proprietatea personalizată a matricei aFieldNames care este utilizată ca sursă de rând pentru lista derulantă a numelor de câmp din imaginea de mai sus. După ce se asigură că aliasul specificat este disponibil, metoda SetForm folosește funcția afieldso pentru a crea laFields, o matrice locală care conține numele câmpurilor din aliasul transmis. Deoarece nu dorim să permitem utilizatorului să includă câmpuri de notă în nicio condiție de filtrare, scanăm matricea laFields pentru a elimina toate câmpurile de notă astfel:

LOCAL lnFieldCnt, laFields[1], lnCnt, lcCaption, InArrayLen

CU Thisform

*** Asigurați-vă că aliasul este disponibil

DACĂ !FOLOSIT( .cAlias )

UTILIZAȚI ( .cAlias ) ÎN 0

ENDIF

*** Obțineți toate numele câmpurilor din aliasul transmis

lnFieldCnt = AFIELDS( laFields, .cAlias )

*** Nu includeți câmpuri de note în lista de câmpuri

lnArrayLen = lnFieldCnt

lnCnt = 1

FACEȚI CÂND lnCnt <= lnArrayLen

IF lnCnt > lnFieldCnt

IEȘIRE

ENDIF

IF TYPE( .cAlias + "." + laFields[ lnCnt, 1 ] ) = "M"

=ADEL( laFields,lnCnt )

lnFieldCnt = lnFieldCnt - 1

ALTE

lnCnt = lnCnt + 1

ENDIF

ENDDO

După ce câmpurile de memorare au fost eliminate, matricea, ThisForm.aFieldNames, este construită folosind elementele rămase din matricea laFields. Thisform.aFieldNames conține două coloane. Prima coloană conține legenda câmpului dacă aliasul transmis este un tabel sau o vizualizare în dbc curent și proprietatea de lege pentru câmp nu este goală. Dacă aliasul transmis este un tabel liber sau legenda sa este goală, prima coloană a matricei conține numele câmpului. A doua coloană a matricei conține întotdeauna numele câmpului:

DIMENSIUNEA .aFieldNames[ lnFieldCnt,2 ]

FOR lnCnt = 1 TO lnFieldCnt

lcCaption = ""

IF !EMPTY( DBC() ) AND ( INDBC( .cAlias, 'TABLE' ) ;

SAU INDBC( .cAlias, 'VIEW' ) )

lcCaption = PADR( DBGetProp( .cAlias + "." + laFields[ lnCnt, 1 ], ;

„FIELD”, „CAPTION” ), 40 )

ENDIF

IF EMPTY( IcCaption )

IcCaption = PADR( laFields[ lnCnt, 1 ], 40 )

ENDIF

.aFieldNames[ lnCnt, 1 ] = lcCaption

.aFieldNames[ lnCnt, 2 ] = PADR( laFields[ lnCnt, 1 ], 40 ) ENDFOR

.cboFieldNames.Requery()

.cboFieldNames.ListIndex = 1

SE TERMINA CU

Este metoda personalizată BuildFilter a formularului care adaugă condiția curentă la filtru. Este invocat de fiecare dată când se face clic pe butonul ADAUGĂ CONDIȚIE:

LOCAL lcCondition

CU Thisform

IF TYPE( .cAlias + '.' + ALLTRIM( .cboFieldNames.Value ) ) = 'C'

lcCondition = 'UPPER(' + AT.T.TRIM( .cboFieldNames.Value ) + ') ' + ;

ALLTRIM( Thisform.cboConditions.Value ) + ' '

ALTE

lcCondition = ALLTRIM( .cboFieldNames.Value ) + ' ' + ;

ALLTRIM( Thisform.cboConditions.Value ) + ' '

ENDIF

*** Adăugați ghilimele dacă tipul câmpului este caracter

IF TYPE( .cAlias + '.' + ALLTRIM( .cboFieldNames.Value ) ) = 'C'

lcCondition = lcCondition + CHR( 34 ) + ;

UPPER( ALLTRIM( .txtValues.Value ) ) + CHR( 34 )

ALTE

lcCondition = lcCondition + at.t.trim ( .txtValues.Value )

ENDIF

*** Dacă există mai multe condiții și ele împreună

.cFilter = IIF( EMPTY( .cFilter ), lcCondition, .cFilter + ;

„ȘI” + lcCondiție)

SE TERMINA CU

Thisform.edtFilter.Refresh()

Nu există nicio validare efectuată asupra valorilor introduse pentru condiția de filtru. Acesta este ceva pe care cu siguranță veți dori să adăugați dacă utilizați acest formular mic ca bază a unui generator SQL în aplicația dvs. de producție. Acest lucru ar putea fi realizat prin adăugarea unei metode ValidateCondition la formular. Această metodă va fi apelată de metoda BuildCondition și va returna un adevărat logic dacă caseta de text conține o valoare adecvată pentru tipul de date al câmpului selectat în lista verticală. Funcția noastră Str2Exp introdusă în Capitolul 2 ar ajuta la îndeplinirea acestui obiectiv.
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Cum pot simula fereastra de comandă în executabilul meu? (Exemplu: Comandă. sex)

Ocazional, este posibil să găsiți necesar să ghidați un utilizator final al aplicației dvs. de producție printr-o operațiune simplă, cum ar fi răsfoirea unui anumit tabel. S-ar putea să credeți că utilizatorii dvs. au nevoie de o copie de Visual FoxPro pentru a face acest lucru. Neadevarat! Cu o formă simplă, câteva linii de cod și o mică extindere a macrocomenzii, puteți crea cu ușurință un simulator de fereastră de comandă pentru a vă ajuta să îndepliniți această sarcină.

Comenzi

utilizați clientul

Figura 11.5 Fereastra de comandă Simulateci pentru executabilul dumneavoastră

Formularul Fereastra de comandă constă dintr-o casetă de editare și o casetă de listă. Metoda personalizată ExecuteCmd a formularului este invocată ori de câte ori utilizatorul introduce o comandă în caseta de editare și apasă tasta Enter.

Comanda este, de asemenea, adăugată în caseta de listă folosind acest cod în metoda KeyPress a casetei de editare:

*** dacă tasta <ENTER> este apăsată, executați coirmand

DACĂ nKeyCode =13

*** Asigurați-vă că există o comandă de executat

IF !EMPTY( Aceasta.Valoare )

CU Thisform

*** Adăugați comanda la lista de povești coirmand hi

.IstHi story .Additemi ALLTRIM ( This.Value ) )

*** Executați comanda

.ExecuteCmd( ALLTRIM( This.Value ) )

SE TERMINA CU

*** Goliți caseta de editare

Aceasta.Valoare

Aceasta.SelStart = 0

ENDIF

*** Nu puneți un retur de transport în caseta de editare!

NODEFAULT

ENDIF

O comandă poate fi, de asemenea, selectată pentru execuție, evidențiind-o în caseta de listă și apăsând ENTER sau făcând dublu clic pe ea. Metoda dblClick a casetei de listă are cod pentru a afișa comanda curentă în caseta de editare și pentru a invoca metoda ExecuteCmd a formularului. Comanda este executată, prin substituție de macro, în această metodă:

LPARAMETRI tcConmand

*** Ieșire directă către _ecran

ACTIVAȚI ECRANUL

*** Executați comanda

&tcComandă

*** Reactivați acest formular

ACTIVAȚI FEREASTRA FrmConmand

Dacă comanda este invalidă sau a fost introdusă incorect, metoda Eroare a formularului afișează mesajul de eroare. Acesta este tot ceea ce este necesar pentru a oferi executabilului dumneavoastră funcționalitatea de bază a ferestrei de comandă.
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Wrapper-uri pentru funcțiile comune Visual FoxPro (Exemplu:

CHU. VCX::cntGetFile și CHU. VCX: : cntGetDir)

Găsim că există anumite funcții Visual FoxPro pe care le folosim din nou și din nou în aplicațiile noastre. GetFiieo și GetDiro sunt două care vin imediat în minte. setnieo este deosebit de supărător pentru că acceptă atât de mulți parametri. Nu ne putem aminti niciodată pe toate și trebuie să mergem la fișierul Ajutor de fiecare dată când invocăm funcția. Crearea unei mici clase de ambalare pentru aceasta are două beneficii majore. În primul rând, oferă utilizatorilor noștri finali o interfață consistentă ori de câte ori trebuie să selecteze un fișier sau un director. În al doilea rând, nu mai trebuie să ne referim la fișierul Ajutor de fiecare dată când trebuie să folosim funcția GetFiieo. Toți parametrii săi sunt acum proprietăți ale clasei container și sunt bine documentați.

Selectați fișierul: [

în dosar:

Figura 11.6 Clasele Wrapper pentru GetFileQ și GetDir() în acțiune

CntGetFile este clasa container utilizată pentru a încheia funcția cetnieo. Este format din două casete de text și un buton de comandă. Prima casetă text conține numele fișierului returnat de funcție. A doua casetă de text conține calea. Butonul de comandă este folosit pentru a invoca funcția cetnieo cu

parametrii corespunzători. Următorul tabel listează proprietățile personalizate utilizate pentru parametrii acceptați de GetFile ()

Tabelul 11.2 Proprietăți personalizate cntGetFile utilizate ca parametri pentru GetFile()

Explicația proprietății	
cFileExtensions 	Specifică extensiile fișierelor afișate în caseta de listă atunci când „Toate fișierele” nu este selectat. Când se alege „Tabele” din lista Tip de fișiere, sunt afișate toate fișierele cu extensia .dbf. Când se alege „Forms” din lista Files of Type, sunt afișate toate fișierele cu extensii .scx și .vcx.
cText 	Text pentru lista de directoare din caseta de dialog Deschidere
cTitleBarCaption 	Legendă din bara de titlu pentru caseta de dialog GetFile().
nButtonType 	0: butoanele OK și Cancel. 1: Butoanele OK, Nou și Anulare 2: Butoanele OK, Niciunul și Anulare „Fără titlu” este returnat cu calea specificată în caseta de dialog Deschidere dacă nButtonType este 1 și utilizatorul alege butonul Nou
cOpenButtonCaption 	Legendă pentru butonul OK

Pentru a utiliza clasa, trebuie doar să o plasați pe formular, să setați toate sau niciuna dintre proprietățile specificate mai sus și ați terminat. Numele de fișier complet calificat returnat de la funcția GetFueo este stocat în proprietatea personalizată cFileName a containerului.

CntGetDir include funcția nativă Getniro și funcționează într-un mod foarte similar. Parametrii acceptați de funcție sunt proprietăți personalizate ale containerului, iar valoarea returnată a funcției este stocată în proprietatea sa personalizată cPath.
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Cursuri de prezentare

Un stoc de cursuri standard de prezentare îți va face viața de dezvoltator mult mai ușoară. Aceste clase de prezentare sunt, în general, clase compuse pe care le-ați „conservat”, deoarece efectuează sarcini comune care sunt necesare în multe părți diferite ale aplicației. Aceste clase de prezentare tind să fie specifice aplicației. De exemplu, un antet vizual de client sau o clasă de antet de comandă va accelera dezvoltarea tuturor formularelor care afișează informații despre clienți sau comenzi. Nu numai că clasele de prezentare ca acestea vă permit să dezvoltați aplicații mai rapid, dar, de asemenea, oferă aplicației un aspect și o senzație consistentă, care va fi apreciată de utilizatorii finali.

Deși clasele de prezentare tind să fie specifice aplicației, avem câteva pe care le folosim în multe aplicații.

Clasa de căutare a codului poștal (Exemplu: CHU. VCX::cntAddress și GetLocation.scx)

În general, cu cât utilizatorul final trebuie să atingă de mai puține ori tastatura, cu atât mai bine va rula aplicația dvs. Când puteți găsi modalități de a reduce cantitatea de informații care trebuie introduse, puteți reduce numărul de greșeli făcute în timpul procesului de introducere a datelor. Acesta este motivul pentru care clasele de căutare precum cea prezentată în această secțiune sunt atât de utile. Introducerea informațiilor despre adrese se pretează la acest tip de implementare, deoarece listele de coduri poștale sunt ușor disponibile dintr-o varietate de surse.

^ Exemplu de clasă de prezentare: Adresa clientului



Companie | Doolittle și Daily

Cod poștal: [44

Note

Abordare

Oraș:

Stat/Provincie

Țară

Yada

Prea noi I

Figura 11.7 Formularul de căutare a codului poștal numit din clasa de prezentare

Când tabelul de căutare a codurilor poștale sau a codurilor poștale este folosit pentru a completa un set de câmpuri de adresă, toate informațiile relevante (oraș, provincie sau stat și țară, dacă este necesar) sunt copiate din tabelul de căutare. Adică, informațiile despre adresă nu sunt normalizate din tabelul care le conține. Tabelul de căutare a codurilor poștale este folosit doar pentru a completa câmpurile obligatorii cu informațiile corecte dacă este găsit. În mod obișnuit, listele de coduri poștale sunt achiziționate de la și întreținute de o terță parte. Schimbarea unor astfel de tabele la nivel local nu este o idee bună, deoarece nu există nicio garanție că următoarea actualizare nu va bloca aceste modificări.

Formularul pop-up este apelat din metoda personalizată FindCity a clasei de prezentare cntAddress. Containerul de adrese arată astfel și poate fi aruncat pe orice formular care trebuie să afișeze o adresă:

=' Class Designer - chit

clasa containerului

Figura 11.8 Adresă standard

Containerul nostru de adresă și formularul de căutare asociat se așteaptă să aibă prezent o vizualizare parametrizată numită Iv PostalCode. Această vizualizare conține informații despre oraș, stat și țară prin cod poștal și are următoarea structură:

Tabelul 11.3 Structura vederii parametrizate lv_PostalCode

Nume câmp 	Tip de dateDescriere
Caracterul orașului Numele orașului	
Sp_Name 	CharacterState/Province/Region Name
poștal 	Caracter Cod poștal
Ctry_Name 	CharacterCountry Name

1 	1 Il 1	
Pc_Key 	IntegerPostal Code Primary Cheie

Parametrul de vizualizare, vp_PostalCode, determină modul în care este populată vizualizarea. Deci, dacă doriți să utilizați această clasă container și formularul de căutare asociat, aveți două opțiuni. Puteți crea vizualizarea parametrizată lv_PostalCode din tabelele dvs. de căutare, așa cum este descris mai sus. Sau puteți modifica la clasa container și formularul de căutare pentru a utiliza structura tabelului de căutare a codurilor poștale. Rezultatul este o clasă care poate fi folosită oriunde trebuie să afișați sau să căutați informații despre adresă în aplicația dvs.

Clasa container de adrese are o proprietate personalizată numită IPostalCodeChanged. Această proprietate este setată la false atunci când txtPostalCode primește focus. Este setat la true în metoda InterActiveChange a casetei de text. Acest lucru se face astfel încât să avem o modalitate de a ști, în metoda FindCity a containerului, dacă utilizatorul a tastat de fapt ceva în caseta de text codul poștal. FindCity este invocat atunci când caseta de text cod poștal pierde focalizarea. În mod clar, dacă utilizatorul nu a făcut modificări la conținutul casetei de text, nu dorim să căutăm codul poștal și să populam casetele de text din container:

LOCAL vp_PostalCode, locație, lnTop, lnLeft

*** Verificați dacă utilizatorul a schimbat codul poștal

*** Dacă nu s-a schimbat nimic, nu vrem să facem nimic

DACĂ ! This.lPostalCodeChanged

ÎNTOARCERE

ENDIF

*** Obțineți toate înregistrările din tabelul de căutare pentru acest cod poștal

vp_PostalCode = ALLTRIM( This.txtPostalCode.Value )

REQUERY( 'lv_PostalCode' )

Dacă vizualizarea conține mai mult de o singură înregistrare, trebuie să prezentăm utilizatorului un formular pop-up din care poate selecta o singură intrare. Folosim funcția OBJTOCLIENT pentru a trece coordonatele de sus și stânga în formularul pop-up, astfel încât să se poată poziționa frumos sub caseta de text codului poștal:

*** Dacă s-au găsit mai multe potriviri, apare ecranul de selecție a orașului/stat

DACĂ RECCOUNT( 'lv_PostalCode' ) > 1

*** Obțineți coordonatele la care să apară formularul

*** Fă-l frumos, astfel încât să apară chiar sub caseta de text

lnTop = OBJTOCLIENT( This.txtAddress, 1 ) + This.txtAddress.Height + ;

Acest formular.Sus

lnLeft = OBJTOCLIENT( This.txtAddress, 2 ) + Thisform.Left

Formularul pop-up este modal. Trebuie să fie dacă ne așteptăm să obținem o valoare returnată din formular folosind următoarea sintaxă. Trecem din forma parametrul de vizualizare si coordonatele la care ar trebui sa se pozitioneze. Formularul modal returnează un obiect care conține detaliile de înregistrare ale articolului selectat, dacă unul a fost selectat în formularul de căutare:

FORM GetLocation WITH vp_PostalCode, lnTop, lnLeft TO location

*** Acum verificăm locația pentru a vedea ce a returnat formularul modal

Cu asta

*** Deoarece stocăm informații despre adresă în evidența clientului

*** vrem să ne asigurăm că nu lovim nimic din ceea ce a fost introdus

*** care NU se află în căutarea codului poștal

IF !EMPTY( locație.CodPoștal )

.txtPostalCode.Value = locație.CodPoștal

ENDIF

IF !EMPTY( locație.Oraș )

.txtCity.Value = locație.Oraș

ENDIF

IF !EMPTY( locație.StateProv )

.txtState.Value = locație.StateProv

ENDIF

IF !EMPTY( locație.Țara )

.txtCountry.Value = locație.Țară

ENDIF

SE TERMINA CU

ALTE

Dacă există fie o înregistrare care se potrivește, fie nicio înregistrare care se potrivește, nu dorim să apară formularul de selecție a orașului. Vrem doar să completăm casetele de text cu informațiile din tabelul de căutare. Dacă doriți să permiteți utilizatorului să adauge o nouă intrare în tabelul de căutare, puteți apela formularul de întreținere corespunzător de aici dacă vizualizarea nu conține înregistrări:

Cu asta

IF !EMPTY( lv_PostalCode.PostalCode )

.txtPostalCode.Value = lv_PostalCode.PostalCode

ENDIF

IF !EMPTY( lv_PostalCode.City )

.txtCity.Value = lv_PostalCode.City

ENDIF

IF !EMPTY( lv_PostalCode.Sp_Name )

.txtState.Value = lv_PostalCode.sp_name

ENDIF

IF !EMPTY( lv_PostalCode.Ctry_Name )

.txtCountry.Value = lv_PostalCode.Ctry_name

ENDIF

SE TERMINA CU

ENDIF

Formularul de selecție a locației folosește parametrii trecuți la metoda sa Init pentru a se poziționa corespunzător și a completa caseta de listă. Obiectul care returnează informațiile selectate este populat în metoda sa Unload.

Formular de conectare generic (Exemplu: LogIn.scx)

Aproape fiecare aplicație necesită ca utilizatorul să se autentifice, fie ca parte a unui model de securitate, fie pur și simplu să înregistreze numele utilizatorului actual (astfel știm pe cine să dăm vina când lucrurile merg prost!). Această mică formă

utilizează o vizualizare care listează toate numele de utilizator curente și parolele asociate acestora și verifică dacă valorile introduse sunt valide. Dacă totul este bine, formularul returnează numele de utilizator curent, în caz contrar, returnează un șir gol.

Rețineți că nu contează modul în care vă stocați de fapt informațiile despre utilizator, cu condiția să puteți crea o vizualizare numită lv_UserList cu două câmpuri (numite UserName și Password) care să conțină o listă de nume de autentificare valide și parolele asociate acestora pentru a fi utilizate de către acesta. formă.

Figura 11.9 Formular de conectare generic

Construcția formularului de autentificare

Formularul de conectare este într-adevăr foarte simplu și are trei proprietăți personalizate și trei metode personalizate, după cum urmează:

Tabelul 11.4 Proprietățile și metodele formularului de conectare

PEM 	TipDescriere
cUserName 	PropertyUser Log-ln nume, returnat după conectarea cu succes
nAttempts 	PropertyRecords numărul de încercări eșuate de autentificare
n Proprietatea Atente max.Determină 	numărul de încercări permise unui utilizator înainte de oprire
Cancel 	MethodCloses Log-ln Form și returnează un șir gol

		
ValidateUserName 	MethodCheck Numele de utilizator se află în lista curentă de utilizatori validi
ValidatePassword 	MethodCheck Parola este corectă pentru numele de utilizator dat

Când formularul este instanțiat, focalizarea este setată pe câmpul de intrare Nume utilizator. Metoda Valid a acestui câmp permite utilizatorului să folosească butonul „Anulare” pentru a închide formularul, dar în caz contrar nu va permite focalizării să părăsească câmpul decât dacă metoda ValidateUserName a formularului returnează .t. Acest formular a fost configurat astfel încât atât introducerea numelui de utilizator, cât și a parolei să țină cont de majuscule și minuscule (deși este posibil să preferați o abordare diferită). Metoda ValidateUserName este foarte simplă și verifică doar pentru a vedea dacă ceea ce a fost introdus de utilizator se potrivește cu o intrare din vizualizarea lv_userlist a formularului, după cum urmează:

SELECT lv_UserLÌst

*** Obțineți doar o potrivire exactă!

LOCATE FOR ALLTRIM( lv_UserList.UserName ) == ALLTRIM( Thisform.txtUserName.Value )

DACA ESTE GASIT()

*** Numele de utilizator nu este valid

Thisform.txtUserName.Value = ''

MESSAGEBOX( „Nu vă recunoaștem. Vă rugăm să vă reintroduceți numele”, ;

16, „Nume de utilizator invalid” )

RETURNARE .F.

ALTE

*** Numele de utilizator este valid - salvați-l în proprietatea formularului

Thisform.cUserName = ALLTRIM( Thisform.txtUserName.Value )

ENDIF

Câmpul de introducere a parolei se comportă foarte similar, deși, deoarece acesta este accesibil numai după ce a fost introdus un nume de utilizator valid, metoda ValidatePassword verifică doar înregistrarea selectată în prezent pentru a vedea dacă parola furnizată se potrivește cu cea necesară pentru numele de utilizator:

SELECTează lv_UserList

IF ALLTRIM( lv_UserList.Password ) == ALLTRIM( Thisform.txtPassword.Value )

*** Totul este pur și simplu pasionat de piersici

ALTE

*** Parola a fost incorectă!

Thisform.txtPassword.Value = ''

*** Creștere contor de încercări

Thisform.nAttempts = Thisform.nAttempts + 1

*** Verificați dacă nu am atins numărul maxim de încercări permise

IF Thisform.nAttempts = Thisform.nMaxAttempts

*** Încă nu e bine - aruncați utilizatorul afară!

MESSAGEBOX( 'Evident că nu vă amintiți parola. La revedere!', ;

16, „Prea multe încercări proaste de conectare” )

Thisform.Cancel()

ALTE

*** Permite o altă încercare

MESSAGEBOX( 'Parolă nevalidă. Vă rugăm să reintroduceți.', 16, 'Parolă nevalidă' )

RETURNARE .F.

ENDIF

ENDIF

Numărul de încercări pe care un utilizator are voie să le facă este controlat de proprietatea nMaxAttempts, care este setată implicit la 3.

Folosind formularul de autentificare

Formularul este definit ca o formă modală, astfel încât să poată fi executată în rutina de pornire a unei aplicații folosind sintaxa do form <«> to <variable>. Acțiunea întreprinsă după rularea formularului de autentificare va depinde, evident, de rezultat și un cod similar cu următorul poate fi utilizat în programul de pornire al aplicației:

CURATA TOT

CLAR

Autentificare FORMULAR LA lcUserId

IF EMPTY (lcUserID)

*** Autentificare eșuată

PĂRĂSI

ENDIF

*** Autentificare - Continuarea a fost realizată cu succes

Clasa casetei de text de căutare (Exemplu: CH11.VCX::txtlookup și Contacts.SCX )

Este adesea posibil să se ocupe de căutarea și afișarea informațiilor pe un formular doar prin stabilirea unei relații în tabelul de căutare. Dacă, totuși, tabelul de căutare nu are o etichetă de index adecvată pentru a fi utilizată într-o relație, aveți nevoie de o altă modalitate de a face acest lucru. Acesta este momentul în care este util să aveți o casetă de text care poate efectua o căutare și apoi afișa rezultatul. Clasa casetei de text de căutare, utilizată pentru a afișa tipul de contact în formularul Contacts.scx din imaginea de mai jos, vă permite să gestionați această sarcină prin simpla setare a câteva proprietăți.

Figura 11.10 Clasa de casetă text de căutare în uz

Caseta de text este concepută pentru a fi utilizată nelegată și, în schimb, utilizează tabelul și câmpul specificat în proprietatea sa cControlSource pentru a determina valoarea pe care ar trebui să o ia ca ControlSource.

Tabelul 11.5 Proprietăți personalizate pentru clasa casete de text de căutare

Descrierea proprietății	
cAlias 	Alias numele tabelului care trebuie căutat
cControlSource 	Table and Field care conține valoarea cheie de utilizat în căutare
cRetField 	Câmp din tabelul de căutare a cărui valoare urmează să fie returnată
cSchField 	Câmp din tabelul de căutare în care trebuie căutată cheia
cTagToUse 	Numele etichetei index de utilizat în căutare (Opțional)

Inițializarea casetei de text de căutare

Când caseta de text este inițializată, își setează Valoarea la conținutul câmpului specificat, evaluând proprietatea cControlSource în metoda Init, după cum urmează:

DODEFAULT()

*** Sursa de control pentru copiere

IF EMPTY(This.ControlSource) ȘI !EMPTY(This.cControlSource)

This.Value = EVAL(This.cControlSource)

ENDIF

Actualizarea căutării

O metodă personalizată (UpdateVaÎ) este apelată din metoda nativă Refresh pentru a gestiona căutarea reală după cum urmează:

LOCAL lcRetFld, luSchVal, lcSchFld, luRetVal

*** Dacă a fost specificat tabel, adăugați-l la numele câmpurilor de căutare și returnare

IF !EMPTY(THIS.cAlias)

lcRetFld = This.cAlias + '.' + This.cRetField

lcSchFld = This.cAlias + '.' + This.cSchField

ALTE

lcRetFld = This.cRetField

lcSchFld = This.cSchField

ENDIF

*** Obțineți valoarea actuală a cheii

luSchVal = EVAL(This.cControlSource)

DACĂ ! EMPTY(luSchVal)

*** Do LookUp - folosind index dacă a fost specificat unul

IF EMPTY(This.cTagToUse)

luRetVal = LOOKUP(&lcRetFld, luSchVal, &lcSchFld)

ALTE

luRetVal = LOOKUP(&lcRetFld, luSchVal, &lcSchFld, This.cTagToUse)

ENDIF

ALTE

luRetVal = " "

ENDIF

*** Actualizați afișajul

DACĂ ! GOL (luRetVal)

This.Value = luRetVal

ALTE

This.Value = ""

ENDIF

Folosind clasa caseta de text de căutare

Deoarece baza pe care funcționează clasa este că este întotdeauna nelegată, poate fi folosită doar ca un control „afișare” doar pentru citire. Mai mult decât atât, nu poate fi folosit în interiorul unei grile pentru că nu ar exista nicio modalitate ca controlul să determine, pentru altceva decât rândul curent, ce ar trebui să fie afișat. Având în vedere aceste limitări, clasa este încă utilă pentru acele ocazii când este necesar să se afișeze rezultatul unei căutări într-un mediu interactiv. Tot ce trebuie să faceți este să setați cControlSource personalizat la numele câmpului care conține cheia externă din tabelul de căutare. În formularul nostru exemplu, acesta este Contact.ct_key. Puneți numele tabelului de căutare în proprietatea sa personalizată cAlias. CSchField și

Proprietățile cRetField trebuie să conțină numele câmpurilor din tabelul de căutare care conțin valoarea cheii și textul descriptiv de afișat. Dacă tabelul de căutare este indexat pe această valoare cheie, plasați numele acestei etichete în proprietatea personalizată cTagToUse a controlului.
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Concluzie

Un stoc de cursuri de prezentare generice vă va oferi o creștere mare a productivității, deoarece le puteți folosi din nou și din nou. Nu numai că vă vor ajuta să produceți aplicații mai rapid, dar vă vor ajuta și la reducerea numărului de erori pe care trebuie să le remediați, deoarece acestea sunt testate de fiecare dată când le utilizați. Sperăm că acest capitol v-a oferit câteva clase pe care le puteți folosi imediat, precum și câteva idei pentru a crea noi clase și mai utile.
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Capitolul 12 - Instrumente de productivitate pentru dezvoltatori

„Într-o societate industrială care confundă munca și productivitatea, necesitatea de a produce a fost întotdeauna un dușman al dorinței de a crea.” ("Revoluția vieții de zi cu zi" de Raoul Vaneigem)

Instrumentele incluse în acest capitol au fost dezvoltate pentru a ne simplifica viața ca dezvoltatori. Niciuna dintre acestea nu ar fi în mod normal disponibilă (sau chiar utilă) într-o aplicație, dar toate sunt membri permanenți ai setului nostru de instrumente de dezvoltare. Acestea fiind spuse, niciunul dintre aceste instrumente nu este cu adevărat terminat. Există întotdeauna ceva mai mult care ar putea fi adăugat și sperăm că, la fel ca noi, vă veți bucura să adăugați propriile voastre.
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Editor de biblioteci de formulare/clase (Exemplu: ClasEdit.prg)

După cum probabil știți, formatele fișierului Visual FoxPro Form (SCX) și ale fișierului Class Library (VCX) sunt identice. Ambele sunt de fapt tabele Visual FoxPro și singurele diferențe sunt în modul în care sunt utilizate anumite câmpuri și că un fișier SCX poate conține doar detaliile obiectului pentru un singur formular, în timp ce o bibliotecă de clase poate conține multe clase. Deoarece ambele sunt tabele, le putem „hack” pur și simplu folosind fișierul direct ca tabel și deschizând tabelul într-o fereastră de răsfoire. Totuși, acest lucru nu este ușor de realizat deoarece, cu excepția primelor trei câmpuri (Platform, UniquelD și Timstamp), toate informațiile sunt păstrate în câmpuri de memorare. Așa că am creat un formular pentru a afișa mai ușor informațiile conținute fie într-un fișier SCX, fie într-un fișier VCX (Figura 12.1 de mai jos).

Figura 12.1 Editor SCX/VCX

De ce avem nevoie de asta? Cât de des ați dorit să puteți schimba clasa pe care se bazează un obiect conținut într-un formular sau să puteți redefini biblioteca de clasă părinte pentru o clasă? Dacă sunteți la fel ca noi, este ceva ce vrem adesea să facem și nu există altă modalitate simplă de a face acest lucru decât editarea directă a fișierului SCX sau VCX relevant. Cele mai importante câmpuri din fișiere sunt enumerate în Tabelul 12.1 de mai jos:

Tabelul 12.1 Câmpurile principale dintr-un fișier SCX/VCX

FieldName 	folosit pentru
CLASS 	Conține clasa pe care se bazează obiectul
	

CLASSLOC 	Dacă clasa nu este o clasă de bază, câmpul conține numele fișierului VCX care conține definiția clasei. Dacă clasa este o clasă de bază, câmpul este gol.
BASECLASS 	Conține numele clasei de bază pentru acest obiect
OBJNAME 	Conține obiectele Nume instanță
PARENT 	Conține numele containerului imediat al obiectului
PROPRIETĂȚI 	Conține o listă a tuturor proprietăților obiectului și a valorilor acestora, care nu sunt doar lăsate la valorile implicite
PROTEJAT 	Conține o listă a membrilor protejați ai obiectului
METODE 	Conține metoda/codul de eveniment al obiectului
OBJCODE 	Conține versiunea compilată a codului evenimentului în format binar
OLE 	Conține date binare utilizate de controalele OLE
OLE2 	Conține date binare utilizate de controalele OLE
RESERVED1 	Conține „Clasă” dacă această înregistrare este începutul unei definiții de clasă, altfel este goală
RESERVED2 	Adevărat logic (.T) dacă clasa este OLEPUBLIC, în caz contrar, fals logic (.F.)
	

RESERVED3 	Listează toți membrii definiți de utilizator. Prefixul este o metodă, „л” este o matrice, altfel este o proprietate
RESERVED4 	Calea relativă și numele fișierului bitmap-ului pentru o pictogramă de clasă personalizată
RESERVED5 	Cale relativă și nume de fișier pentru o pictogramă de clasă personalizată Manager de proiect sau Class Browser
RESERVED6 	ScaleMode al clasei, Pixeli sau Foxels
RESERVED7 	Descrierea clasei
RESERVED8 	#Include Numele fișierului

Dintre toate aceste câmpuri, este cel mai probabil să dorim să modificăm câmpurile OBJNAME, CLASS și CLASSLOC și acestea sunt cele trei câmpuri pe care le-am plasat primul în grilă. Regiunile de editare de sub grilă arată conținutul câmpurilor Proprietăți și Metode pentru fiecare rând din fișier și, deși puteți edita setările proprietăților, sau chiar codul metodei, direct în aceste ferestre preferăm să lucrăm prin foaia de proprietăți. (Nu am găsit probleme când o facem direct, dar nu se simte în siguranță cumva!)

O caracteristică utilă a formularului este că putem introduce comenzi pe o linie direct în caseta „Run” și le putem executa. După cum arată ilustrația, acest lucru este util pentru gestionarea modificărilor globale ale elementelor din interiorul unei biblioteci de formulare sau de clase.

Folosind editorul SCX/VCX

Pentru a rula editorul, folosim un program simplu, numit clasedit.prg (care este inclus cu exemplul de cod pentru acest capitol). Acest lucru pur și simplu rulează formularul într-o buclă atâta timp cât un nou fișier SCX sau VCX este selectat din dialog. De îndată ce nu se face nicio selecție, bucla iese și eliberează totul. De fiecare dată când editorul este închis, fișierul SCX sau VCX este re-compilat pentru a se asigura că orice modificări care au fost făcute sunt salvate corect.

**************************************************** ********************

* 	Program. ClasEdit.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: rulează Editorul SCX/VCX într-o buclă până când nu există fișier

* 	..........:este selectat în dialogul GetFile().

**************************************************** ********************

LOCAL lcSceFile

CLAR

CURATA TOT

INCHIDE TOT

*** Închide orice bibliotecă deschisă

SETĂ CLASĂ LA

*** Și fișierele SCX/VCX

DACĂ FOLOSIT('vcxedit')

UTILIZAȚI ÎN vcxedit

ENDIF

*** Inițializați variabila de control

FĂ CÂND .T.

*** Obțineți numele fișierului sursă

lcSceFile = GETFILE('SCX;VCX')

IF EMPTY(lcSceFile)

IEȘIRE

ENDIF

*** Deschideți fișierul sursă și setați modul tampon la Optimistic Table

UTILIZAȚI (lcSceFile) ÎN 0 ALIAS EXCLUSIV vcxedit

CURSORSETPROP( „Buffering”, 5 )

*** Rulați formularul

FORMATĂ ClasEdit CU lcSceFile

CITEȘTE EVENIMENTE

*** Compilați fișierul SCX/VCX

IF JUSTEXT( lcSceFile ) = „SCX”

COMPILARE FORMULAR (lcSceFile)

ALTE

COMPILARE CLASSLIB (lcSceFile)

ENDIF

ENDDO
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Inspector de formulare (Exemplu: InspFprm.scx și ShoCode.scx)

Acest mic instrument simplu oferă posibilitatea de a inspecta o formă și toate obiectele sale în timp ce acea formă rulează efectiv. Există mai multe moduri de a face acest lucru, dar ne place acesta deoarece este simplu, ușor de utilizat și ne permite să obținem o privire „rapidă și murdară” asupra a ceea ce face un formular atunci când îl rulăm în modul de dezvoltare. De asemenea, ne permite să setăm sau să schimbăm proprietățile formularului sau ale oricărui obiect din formular, în mod interactiv.

Formularul este conceput pentru a accepta o referință de obiect la un formular activ și pentru a afișa informații despre acel formular în cadrul de pagină. De obicei, îl folosim setând o comandă On Key Label ca aceasta:

PE Eticheta tastei CTRL+F9 DO FORM inspForm CU _Screen.ActiveForm

Pagina cu informații despre tabel

Când este activată, este afișată pagina „Informații despre tabel”. Caseta cu listă de pe această pagină arată orice tabel care este utilizat de formularul țintă. (Dacă formularul nu folosește niciun tabel, singura intrare din această casetă de listă va fi „Fără tabele utilizate”). Selectarea unui tabel din listă completează câmpurile asociate care arată starea acelui tabel și grila care arată înregistrarea curentă. Detalii.

Figura 12.2 Form Inspector - pagina cu informații tabel

Pagina de informații din formular

A doua pagină a formularului conține o casetă listă care este populată atunci când formularul este inițializat, folosind funcția nativă memberso, cu toate proprietățile, evenimentele, metodele și orice obiecte din formularul țintă.

w Formular de inspectare: Sample Multi

Tabele 	FormMembersObject List

Metoda BOXж |	
MOD TAMPON 	2I
CAPTION 	Exemplu de formular cu mai multe mese—I
Metoda CERCLE	
CLASS 	Frmsample
CLASSLIBRARY 	c:\vfp60\ch12ïch12.vcx
CLICK 	Eveniment
CLIPCONTROLS 	.T.
C LO SAB LE 	.T.
Metoda CLS	
Obiect CMDEXIT	
CMDNEXT 	Obiect
CMDPREVIOUS 	Obiect
SURSA DE CULOARE 	44

Ieșire

Figura 12.3 Form Inspector - pagina de informații formular

Făcând dublu clic pe o metodă sau un eveniment din această listă, se afișează o fereastră modală care conține orice cod asociat cu metoda respectivă în formular (Notă: numai codul care a fost adăugat direct în formular este vizibil în acest fel, codul moștenit nu va fi văzut Aici):

& Cod pentru: Frmsamplet ::CLICK

*** Obțineți o listă cu toate proprietățile, metodele și membrii obiectului InObj = AMEMBERS( laObj, ThisForm.oCallingForm, 1 ) *** Creați cursorii necesari

CREATE CURSOR curFormObj ( ;

cNume 0(30))

CREATE CURSOR curFormProp ( ;

cProp 0(40), ;

cValoare C(40))

„* Populați cursoarele pentru proprietatea formularului și Lista de obiecte FOR lnCnt = 1 TO InObj

IF L0WER( laObj[lnCnt,2] ) = „obiect”

Închide

Figura 12.4 Form Inspector - afișaj cod

Făcând dublu clic pe o proprietate, apare un dialog care vă permite să modificați valoarea proprietății respective. (Waming: Nu există nicio verificare a erorilor asociată cu această funcție și dacă încercați să setați o proprietate care este doar pentru citire, Visual FoxPro va genera o eroare. Acesta este un instrument „rapid și murdar”!)

Valoare setată pentru: irmi

Introduceți o valoare numerică

I 	12632256

Ieșirea I

Figura 12.5 Form Inspector - dialog de setare a proprietăților

În cele din urmă, dublu clic pe un obiect populează a treia pagină a formularului cu proprietățile, evenimentele, metodele și orice obiecte conținute pentru acel obiect.

Pagina cu lista de obiecte

A treia pagină este folosită pentru a afișa detaliile oricărui obiect din formular. Ca și în cazul listei de formulare, dublu clic pe o metodă sau eveniment afișează orice cod asociat cu metoda respectivă, iar dublu clic pe o proprietate afișează dialogul de setare. Rețineți că codul metodei este preluat folosind funcția «stremo și pare să existe o eroare în această funcție în versiunea 6.0, așa că nu va prelua codul care există în metodele unei „pagini”. Codul din orice obiect dintr-o pagină sau din metodele cadru de pagină este preluat corect, dar metodele paginii sunt întotdeauna goale chiar și atunci când au cod la nivel de instanță.

Figura 12.6 Form Inspector - pagina de informații despre obiect

Făcând dublu clic pe un obiect din această casetă listă, lista se repopulează cu detaliile acelui obiect și se actualizează linia „Obiect curent” de pe pagină. Făcând clic dreapta în caseta de listă, selectează părintele obiectului curent (dacă există unul) și face posibilă parcurgerea în sus și în jos în ierarhia obiectelor.

Construirea fișei de inspecție

Metodele Init și SetUpForm

Metoda Init este utilizată pentru a primi și stoca referința obiectului la formularul care urmează să fie inspectat la o proprietate de formular. Apoi forțează formularul de inspecție în sesiunea de date a formularului de apelare și setează legenda acestuia să includă legenda formularului de apelare. În cele din urmă, apelează metoda personalizată SetUpForm:

LPARAMETERS toSceForm

IF VARTYPE(toSceForm ) # "O"

*** Nu a trecut un obiect formular

RETURNARE .F.

ENDIF

CU ThisForm

*** Salvați referința la Formularul de apelare

.oCallingForm = toSceForm

*** Setați DataSession la același ca și Formularul de apelare

.DataSessionID = .oCallingForm. DataSessionID

*** Configurați legendă

This.Caption = "Formular de inspectare: " + .oCallingForm.Caption

*** Configurați acest formular

.SetUpForm ()

SE TERMINA CU

Metoda SetUpForm este responsabilă în primul rând pentru popularea casetei cu listă de pe Pagina Unu a formularului de inspecție cu o listă a tabelelor utilizate de formularul de apelare. Apoi apelează metoda personalizată UpdFormProps pentru a popula caseta cu listă de pe pagina „Membri de formular” înainte de a returna controlul procesului de inițializare a formularului. Codul real din metoda SetUpForm este:

LOCAL ARRAY laTables[1]

LnTables LOCAL

*** Obțineți o listă de tabele utilizate în DataSession a formularului de apelare

lnTables = AUSED( laTables, ThisForm.DataSessionId )

*** Construiți un cursor pentru toate mesele deschise

CREATE CURSOR curAlias ( ;

cTabelul C (30);

nZona I( 4) )

DACĂ lnTabele > 0

INSERT INTO curAlias FROM ARRAY laTables

ALTE

INSERT INTO curAlias VALUES („Fără tabele folosite”, 0)

ENDIF

*** Configurați caseta cu listă de tabele

CU ThisForm.pgfMembers.Pagel.lstTables

.RowSourceType = 6

.RowSource = "curalias.cTable, nArea"

.ReQuery()

.ListIndex = 1

SE TERMINA CU

*** Obțineți proprietățile formularului

ThisForm.UpdFormProps ()

Metoda UpdTable

Această metodă personalizată este apelată din metoda Activare a paginii „Tabele” și este responsabilă de completarea câmpurilor de stare și a grilei de pe pagina respectivă, cu detaliile pentru tabelul selectat în prezent. Metoda este apelată și din metoda InterActiveChange a casetei cu listă de pe pagina întâi, astfel încât detaliile să fie păstrate sincronizate cu tabelul selectat în prezent.

LOCAL lcTable, lcMode, lnMode, lnSelect, lcSafety, lcField, lcFVal

CU ThisForm

*** Blocați ecranul în timpul actualizării

.LockScreen = .T.

CU .pgfMembers.page1

lcTable = ALLTRIM(.lstTables.Value)

*** Dacă nu sunt folosite tabele

IF lcTable e „Nu sunt tabele utilizate”

ThisForm.LockScreen = .F.

ÎNTOARCERE

ENDIF

*** Numărul de înregistrări și numărul de înregistrare

.txtRecCount.Value = RECCOUNT( lcTable )

.txtCurRecNo.Value = IIF( EOF(lcTable), „La EOF()”, RECNO( lcTable )) *** Etichetă index curentă și expresie cheie

.txtCurTag.Value = ORDER( lcTable )

*** Modul tampon

lcMode = ""

lnMode = CURSORGETPROP( 'Buffering', lcTable )

lcMode = IIF(lnMode = 1, 			„Fără tamponare”, lcMode)
lcMode = IIF( 	lnMode= 2, „Rând pesimist”, lcMode)
lcMode = IIF( 	lnMode= 3,'Optimist Row', lcMode)
lcMode = IIF( 	lnMode= 4, „Tabel pesimist”, lcMode)	
lcMode = IIF( 	lnMode= 5,'Optimist Row', lcMode)

.txtBufMode.Value = lcMode

*** Starea câmpului

IF lnMode > 1

.txtFldState.Value = NVL( GETFLDSTATE( -1, lcTable ), „La EOF()”)

ALTE

.txtFldState.Value = ""

ENDIF

SE TERMINA CU

*** Detalii despre înregistrarea curentă

lnSelect = SELECT ()

DACĂ FOLOSIT('currec')

lcSafety = SET("SIGURANȚĂ")

OPRITĂ SIGURANȚA

ZAP IN currec

SETARE SIGURANȚĂ &lcSiguranță

ALTE

CREATE CURSOR curRec ( ;

cCâmpul C (40), ;

cValoare C (60) )

ENDIF

SELECTARE (lcTable)

*** Obțineți detaliile înregistrării

FOR lnCnt = 1 TO FCOUNT()

lcField = CAMP (lnCnt)

lcFVal = TRANSFORM( &lcField )

INSERT INTO currec VALUES (lcField, lcFVal)

URMĂTORUL

SELECTARE (lnSelect)

*** Populați și actualizați Grila

CU ThisForm.pgfMembers.Pagel.grdCurRec

.RecordSource = "currec"

GO TOP IN currec

.Seteaza focusul()

SE TERMINA CU

*** Eliberați ecranul

.Ecran de blocare

.F.

SE TERMINA CU

Metoda UpdFormProps

Această metodă personalizată pur și simplu obține lista de membri ai formularului folosind funcția nativă AMEMBERS(). Detaliile sunt scrise pe un cursor local. Singurele elemente complicate aici sunt că anumite proprietăți nu sunt direct recuperabile, fie pentru că sunt de fapt colecții (de exemplu, „Controale”), fie pentru că sunt ele însele referințe la obiecte care au doar valori în formularul de apelare (de exemplu, „ActiveControl”). Acestea sunt excluse în mod special și cuvântul cheie „Referință” este inserat astfel încât să nu provoace probleme mai târziu:

LOCAL ARRAY laObj[1]

LOCAL lnObj, lnCnt, lcProp, lcPName, lcPVal

CU ThisForm

*** Blocare ecran în timpul actualizării afișajului

.LockScreen = .T.

*** Obțineți o listă cu toate proprietățile, metodele și membrii obiectului

lnObj = AMEMBERS( laObj, ThisForm.oCallingForm, 1 )

*** Creați cursoarele necesare

DACĂ FOLOSIT('curFormProp')

UTILIZARE ÎN curformprop

ENDIF

CREATE CURSOR curFormProp ( ;

cProp C(40),;

cValoare C(40) )

*** Populați cursoarele pentru proprietatea formularului și Lista de obiecte

PENTRU lnCnt = 1 LA lnObj

IF LOWER( laObj[lnCnt,2] ) = „obiect”

INSERT INTO curFormProp VALUES (laObj[lnCnt,1], „Obiect”)

ALTE

lcProp = LOWER( laObj[lnCnt,2] )

IF lcProp = „proprietate”

lcPName = LOWER(laObj[lnCnt,1])

*** Ignorați proprietățile care returnează Referințe/Colecții de obiecte

IF lcPName=='coloane' SAU lcPName='pagini' SAU lcPName=='controale' ;

SAU lcPName = 'butoane' SAU lcPName == 'obiecte' ;

SAU lcPName = ' părinte ' SAU lcPName = ' control activ ' ;

SAU lcPName = „activform”

INSERT INTO curFormProp VALUES (laObj[lnCnt,1], „Referință”)

BUCLĂ

ENDIF

*** În caz contrar, obțineți valoarea curentă

lcPVal = TRANSFORM( EVAL("ThisForm.oCallingForm."+laObj[lnCnt,1]) )

INSERT INTO curFormProp VALUES (laObj[lnCnt,1], lcPVal)

ALTE

INSERT INTO curFormProp VALUES (laObj[lnCnt,1], laObj[lnCnt,2])

ENDIF

ENDIF

URMĂTORUL

*** Configurați caseta de listă cu proprietăți formular pe pagina 2

CU ThisForm.pgfMembers.page2.lstFormProps

.RowSourceType = 6

.RowSource = "curFormProp.cProp, cValue"

.ReQuery()

.ListIndex = 1

SE TERMINA CU

*** Deblocați ecranul

.LockScreen = .F.

SE TERMINA CU

Metoda UpdObjProps

Această metodă personalizată este în esență aceeași cu metoda UpdFormProps de mai sus, cu excepția faptului că actualizează referința „obiect curent” a formularului de inspecție și preia PEM-urile pentru orice obiect la care trimite această referință în prezent. Informațiile sunt afișate în caseta cu listă de la pagina a treia a formularului de inspecție:

LPARAMETERS tlSetForm

LOCAL ARRAY laObj[1]

loFormObj LOCAL, lnObj, lnCnt, lcProp, lcPName, lcPVal

CU ThisForm

*** Înghețați ecranul în timpul actualizării

.LockScreen = .T.

DACĂ ! tlSetForm

*** Actualizați Referința obiectului curent

loFormObj = EVAL( "Acest.oCurobj." ;

+ ThisForm.pgfMembers.page3.lstObjProps.Value )

*** Salvare obiect curent Ref

.oCurObj = loFormObj

ALTE

loFormObj = .oCurObj

ENDIF

lnObj = AMEMBERS( laObj, loFormObj, 1 )

*** Creați un cursor local

IF USED('curobjlist')

UTILIZAȚI ÎN curObjList

ENDIF

CREATE CURSOR curObjList ( ;

cProp C(40),;

cValoare C(40) )

*** Populați cursorul Lista de proprietăți

PENTRU lnCnt = 1 LA lnObj

lcProp = LOWER.( laObj[lnCnt,2] )

IF lcProp = „proprietate”

lcPName = LOWER(laObj[lnCnt,1])

*** Ignorați proprietățile care returnează Referințe/Colecții de obiecte

IF lcPName = 'coloane' SAU lcPName == 'pagini' SAU lcPName == 'controale' ;

SAU lcPName = 'butoane' SAU lcPName == 'obiecte' ;

SAU lcPName = 'părinte' SAU lcPName = 'activecontrol' ;

SAU lcPName = „activform”

INSERT INTO curObjList VALUES (laObj[lnCnt,1], „Referință”)

BUCLĂ

ENDIF

*** În caz contrar, obțineți valoarea curentă

lcPVal = GETPEM( loFormObj, laObj[lnCnt,1] )

INSERT INTO curObjList VALUES (laObj[lnCnt,1], TRANSFORM(lcPVal ))

ALTE

INSERT INTO curObjList VALUES (laObj[lnCnt,1], laObj[lnCnt,2])

ENDIF

URMĂTORUL

*** Configurați caseta Listă proprietăți obiect pe pagina 3

CU .pgfMembers.page3.lstObjProps

.RowSourceType = 6

.RowSource = "curObjList.cProp, cValue"

.ReQuery()

.ListIndex = 1

SE TERMINA CU

*** Actualizați controlul curent .pgfMembers.page3.txtCurObj.Value = SYS(1272, .oCurObj ) *** Deblocare ecran

.LockScreen = .F.

SE TERMINA CU

Comportamentele casetei de listă

Singurul alt cod semnificativ din formularul de inspecție este în metoda Doubleclick a casetelor cu listă de pe ambele pagini a doua și a treia și, în plus, în metoda RightClick a casetei de listă de pe pagina trei. Codul RightClick este foarte simplu și determină doar dacă obiectul selectat curent are un părinte și, dacă da, face din acel obiect obiectul curent înainte de a apela metoda UpdObjProps a formularului, după cum urmează:

CU ThisForm

*** Verificați părintele

IF TYPE("ThisForm.oCurObj.Parent" ) = "O"

*** Faceți actualitatea părintelui

.oCurObj = .oCurObj.Parent

.updObjProps(.T.)

ALTE

*** Nu face nimic

MESSAGEBOX( „Obiectul curent nu are părinte”, 16, „Nu se poate da înapoi”)

ENDIF

SE TERMINA CU

Codul din metodele Doubleclick este puțin mai complex și utilizează înregistrarea curentă din cursorul la care este legată caseta de listă pentru a determina ce acțiune este necesară. Codul pentru ambele casete de listă este în esență același și arată astfel:

LOCAL lcStr, loCurObj, lcProperty, lcType

CU ThisForm

FACE CAZ

CASE INLIST( curObjList.cValue, 'Metodă', 'Eveniment' )

*** Și avem un obiect

IF VARTYPE( ThisForm.oCurObj ) = "O"

*** Obțineți orice cod în metodă

lcStr = GetPem( ThisForm.oCurObj, ALLTRIM(curObjList.cProp) )

IF EMPTY(lcStr)

lcStr = „Fără cod la acest nivel”

ENDIF

*** Afișați fereastra de cod

DO FORM shoCode WITH lcStr, ;

ThisForm.oCurObj.Name + „::” + ALLTRIM(curObjList.cProp)

ENDIF

CASE curObjList.cValue = „Obiect”

*** Obțineți noi obiecte PEMS

.UpdObjProps(.F.)

CASE curObjList.cValue # „Referință”

*** Trebuie să fie o proprietate - Obțineți valoarea actuală

loCurObj = EVAL( "ThisForm.oCurObj." + alltrim( curObjList.cProp) )

*** Și numele

lcProperty = SYS(1272,ThisForm.oCurObj) + "." + ALLTRIM(curObjList.cProp)

*** Și tipul de date

lcType = TYPE( "loCurObj" )

*** Obțineți o valoare nouă

FORM SetProp WITH lcProperty, lcType, loCurObj TO luNewVal

*** Actualizați proprietatea

lcProperty = "ThisForm.oCurObj." + ALLTRIM( curObjList.cProp)

&lcProperty = luNewVal

*** Actualizați afișajul

.UpdObjProps(.T.)

IN CAZ CONTRAR

*** Ignora!

ENDCASE

SE TERMINA CU
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Constructorul nostru de rețele de rezistență industrială (Exemplu: gridbuild. vcx: :gridbuild)

Când veți face un test de generare a rețelei industriale super duper, veți fi probabil surprins de asemănarea sa strânsă cu generatorul nativ de rețea Visual FoxPro. Această asemănare nu este întâmplătoare. Microsoft livrează codul sursă pentru vrăjitorii și constructorii săi cu Visual FoxPro versiunea 6.0. Deci, dacă aveți nevoie de funcționalitate specială de la un constructor, nu mai trebuie să reinventați roata. Puteți personaliza propriii constructori ai Visual FoxPro. Îi suntem recunoscători în special lui Doug Hennig pentru că ne-a împărtășit munca sa inițială la constructorul de rețea. A facilitat mult dezvoltarea acestei variante a constructorului.

txtgrid

Figura 12.7 Generatorul de rețele cu en ha necesită funcționalitate

Pentru a utiliza generatorul nostru îmbunătățit, mai întâi trebuie să îl înregistrați rulând GridBuildReg.prg inclus cu exemplul de cod pentru acest capitol. Acest program adaugă o înregistrare nouă la Builder. dbf în subdirectorul vrăjitorilor Visual FoxPro. Builder.app folosește acest tabel pentru a determina ce program de constructor să ruleze.

Acum va trebui să reconstruiți GridBuild.pjx, proiectul care conține generatorul nostru de grile de rezistență industrială și este inclus cu exemplul de cod pentru acest capitol. Dacă nu ați făcut deja acest lucru, trebuie să dezarhivați codul sursă pentru constructori, care este furnizat cu Visual FoxPro 6.0. Îl veți găsi în HOME() + „\TOOLS\XSOURCE\XSOURCE.ZIP”. Dezarhivând fișierul folosind setările implicite creează o structură de directoare care începe de la HOME()+'\TOOLS\VFPSOURCE' și se întinde pe mai multe niveluri. După ce ați dezarhivat codul sursă, urmați acești pași pentru a instala generatorul de grile de rezistență industrială:

1. 	Copiați fișierele GridBuild.pjx și GridBuild.pjt din directorul care conține exemplul de cod pentru acest capitol în HOME()+'\TOOLS\VFPSOURCE\BUILDERS.'

2. 	Copiați fișierele GridMain.prg, GridBuild.vcx și GridBuild.vct din directorul care conține codul exemplu pentru acest capitol în folderul HOME()+'\TOOLS\VFPSOURCE\BUILDERS\GRIDBLDR'.

3. 	Acum sunteți gata să reconstruiți proiectul. Construiți GridBuild.App și când este terminat, mutați aplicația în directorul HOME()+'\WIZARDS'.

De acum înainte, generatorul dvs. de rețea va avea funcționalități noi și îmbunătățite. Dacă reinstalați Visual FoxPro sau aplicați un pachet de servicii care suprascrie Builder.dbf, tot ce trebuie să faceți este să rulați din nou GridBuildReg.prg pentru a reînregistra GridBuild.app ca generator de grilă implicit.

Deci, de ce aveam nevoie de un generator de grile îmbunătățit? Generatorul nativ de grilă Visual FoxPro are următoarele neajunsuri:

• 	Nu dimensionează corect coloanele legate, adică pe baza lățimii sursei de control ale acestora

• 	Nu denumește coloanele legate și controalele conținute în mod corespunzător pentru ControlSource a coloanei

• 	Nu există nicio modalitate de a-i spune să folosească clase personalizate

Această versiune a constructorului abordează toate aceste trei probleme, dar, după ce ne-am străduit să punem în funcțiune îmbunătățirile noastre, am început să ne întrebăm dacă nu ar fi fost mai ușor să ne scriem propriul constructor de la zero. A fost foarte drăguț din partea Microsoft să ne ofere acces la codul sursă pentru acești constructori. Ar fi fost și mai frumos dacă ar fi comentat și ar fi depanat! De exemplu, am găsit mai multe erori în constructorul nativ, mai ales când am început să eliminăm coloanele din grilă.

În cele din urmă, am descoperit că codul constructorului nu ar putea gestiona eliminările dacă coloanele aveau alte nume decât „coloana1”, „coloana2” etc. manipulați-le fără să explodeze!

Deoarece am vrut să atingem cât mai puțin din codul original, am redenumit coloanele și anteturile cu numele lor implicite în metoda Load a clasei noastre personalizate GridBuild. Din acest motiv, dacă invocați generatorul și utilizați butonul de anulare pentru a ieși, veți descoperi că toate numele de coloane și antet au fost resetate la numele implicite Visual FoxPro. Acest lucru este ușor de reparat. Doar invocați constructorul și ieșiți apăsând butonul ok.

Cea mai mare parte a funcționalității generatorului de grile nativ poate fi găsită în clasa GridBldr a lui GridBldr.vcx. În cazul în care se adaugă o nouă funcționalitate acestei clase în versiunile viitoare ale Visual FoxPro, am decis să o subclasăm și să ne modificăm subclasa. Veți găsi codul care oferă funcționalitatea îmbunătățită în clasa GridBuild.vcx::GridBuild.

Redimensionarea corectă a coloanelor de grilă

Din fericire, nu a trebuit să ne lovim cu capul de tastatură pentru a ne da seama de asta. Cea mai mare parte a lucrării fusese deja făcută de Doug Hennig și prezentată la a treia conferință anuală Southern California Visual FoxPro din august 1999. Ceea ce a descoperit el a fost că constructorul grilei avea deja o metodă numită SetColWidth pentru a efectua calculele necesare și a redimensiona coloanele. . Cu toate acestea, constructorul a transmis o valoare greșită metodei! După multe săpături şi

experimentând, am descoperit că Visual FoxPro adaugă noi coloane la grilă cu o lățime implicită de 75 de pixeli în metoda sa ResetColumns. Metoda respectivă a efectuat apoi următoarea verificare pentru a decide dacă se dimensionează corect noua coloană în raport cu câmpul legat:

*- nu resetați lățimea dacă utilizatorul a schimbat-o deja

DACĂ wbaTemp[m.wbi,1] # wbaCols[m.wbi,1] ȘI wbaCols[m.wbi,1] # 0

wbaTemp[m.wbi,1] = wbaCols[m.wbi,1]

ENDIF

Deoarece wbaCols[m.wbi, 1] deține ColumnWidth curentă a coloanei care este procesată de către constructorul grilei, nu a fost niciodată egală cu zero și ColumnWidth nu a fost niciodată redimensionată corect. Tot ce trebuia să facem a fost să inițializam ColumnWidth pentru coloanele nou adăugate la zero și au fost redimensionate corect.

Redenumirea coloanelor și a controalelor acestora în mod corespunzător

Am adăugat o metodă numită, destul de ciudat, RenameControls la clasa noastră GridBuild pentru a gestiona această sarcină. Această metodă este apelată din metoda Click a butonului OK al constructorului și redenumește coloanele și controalele conținute în funcție de numele câmpului la care este legată coloana. Această metodă înlocuiește, de asemenea, anteturile clasei de bază și casetele de text ale clasei de bază cu clasele dvs. personalizate dacă a fost specificată o clasă personalizată în pagina „Controale personalizate” a constructorului.

LOCAL LnRows, lnCnt, lcField, loColumn, lcHeader, loHeader, ;

lnCtl, lnControls, lacontrols[ 1, 2 ], lnCount, lcCaption

*** Dacă nu sunt definite coloane, salvați acum

IF wbaControl[ 1 ].ColumnCount = -1

ÎNTOARCERE

ENDIF

lnRows = ALEN( wbaCols, 1 )

Apoi, trecem prin matricea wbaCols a constructorului pentru a redenumi fiecare coloană pentru a reflecta numele câmpului la care este legată. Constructorul stochează numele actual al coloanei în coloana șapte a matricei wbaCols. Numele câmpului la care este legat este stocat în coloana a doua. Constructorul menține un rând în matrice pentru fiecare coloană din grilă:

FOR lnCnt = 1 TO lnRows

lcField = wbaCols[ lnCnt, 2 ]

DACĂ NU EMPTY (lcField)

*** Obțineți numele implicit al coloanei

loColumn = EVALUATE( 'wbaControl[1].' + wbaCols[ lnCnt, 7 ] )

*** Redenumiți coloana și antetul în funcție de numele câmpului

loColumn.Name = 'col' + lcField

wbaCols[ lnCnt, 7 ] = loColumn.Name

Acest cod elimină anteturile clasei de bază și le înlocuiește cu anteturile noastre personalizate dacă această opțiune a fost specificată pe a cincea pagină a constructorului. Apoi redenumește antetul într-un mod compatibil cu coloana în care se află. Rețineți că, atunci când adăugați anteturi personalizate la coloana grilă, trebuie mai întâi să eliminăm toate controalele conținute în coloană, deoarece coloana se așteaptă ca antetul său să fie primul control din colecția de controale. Dacă nu este, grila rezultată nu va funcționa corect. După ce antetul personalizat este adăugat la coloană, restul controalelor sunt adăugate din nou:

DACĂ ThisFormSet.Form1.Pageframe1.Page5.chkCustomHeaders.Value = .T. ȘI ;

„EMPTYC Thisformset.cHeaderClass )

*** Acum eliminați toate anteturile clasei de bază și adăugați anteturi personalizate

*** Trebuie să scoatem toate obiectele din coloană astfel încât

*** antetul personalizat nou adăugat este controale[1]

lnControls = loColumn.ControlCount

lnCount = 0

FOR lnCtl = 1 TO lnControls

IF UPPER( loColumn.Controls[ 1 ].BaseClass ) = 'HEADER'

*** Salvați legenda antetului înainte de a o elimina

lcCaption = loColumn.Controls[ 1 ].Caption

loColumn.RemoveObject( loColumn.Controls[ 1 ].Name )

ALTE

*** Salvați informații despre celelalte controale în coloană

*** înainte de a le îndepărta

lnCount = lnCount + 1

DIMENSIUNE laControls[ lnCount, 2 ]

laControls[ lnCount, 1 ] = loColumn.Controls[ 1 ].Nume

laControls[ lnCount, 2 ] = loColumn.Controls[ 1 ].Class

loColumn.RemoveObject( loColumn.Controls[ 1 ].Name )

ENDIF

ENDFOR

*** Adăugați antetul personalizat

loColumn.AddObject('hdr' + lcField, Thisformset.cHeaderClass )

*** Asigurați-vă că setați legenda

loColumn.Controls[ 1 ].Caption = lcCaption

*** Adăugați înapoi celelalte controale ale coloanei

FOR lnCtl = 1 TO lnCount

loColumn.AddObject( laControls[ lnCtl, 1 ], laControls[ lnCtl, 2 ] )

ENDFOR

ALTE

*** Dacă nu folosim antete personalizate, doar redenumiți-le

loColumn.Controls[ 1 ].Nume = 'hdr' + lcField

ENDIF

Metoda înlocuiește, de asemenea, casetele de text native și le redenumește. Codul care face acest lucru este foarte asemănător cu codul prezentat mai sus.

Pagina Controale personalizate a generatorului de grile

Adăugarea acestei pagini la generatorul de grile a fost probabil cea mai ușoară parte a îmbunătățirii acesteia. A fost, de asemenea, cel mai distractiv pentru că am ajuns să folosim două funcții foarte interesante care sunt noi pentru Visual FoxPro 6.0: FILETOSTR() și alines(). Aceste funcții ne-au permis să completăm caseta combinată din care poate fi selectată o clasă de antet personalizată. Deoarece anteturile personalizate nu pot fi definite vizual și trebuie să fie definite și stocate într-un

fișier de program, aceste două funcții au simplificat foarte mult munca de a analiza numele claselor din fișierul de program. Iată codul nostru cool din metoda Valid a casetei de text care conține numele fișierului de procedură de utilizat:

LOCAL lcProcFile, lcStr, laLines[ 1 ], lnLines, lnCnt, IcClass, InLen

IF EMPTY( ThisformSet.cProcFile )

ÎNTOARCERE

ENDIF

lcProcFile = Thisformset.cProcFile

*** Acum populați combo-ul cu numele

*** a claselor personalizate din dosarul procedurii

This.Parent.cboHeaderClass.Clear()

lcStr = FILETOSTR( lcProcFile )

lnLines = ALINES( laLines, lcStr )

FOR lnCnt = 1 TO lnLines

IF 'DEFINE CLASS' $ UPPER( laLines[ lnCnt ] )

lnLen = AT( 'AS', UPPER( laLines[ lnCnt ] ) ) - 13

lcClass = ALLTRIM( SUBSTR( laLines[ lnCnt ], 13, lnLen ) )

This.Parent.cboHeaderClass.AddItem( lcClass )

ENDIF

ENDFOR

This.Parent.cboHeaderClass.ListIndex = 1

*** Asigurați-vă că este disponibilă clasa de antet personalizată

IF !EMPTY( lcProcFile )

IF lcProcFile $ SET('PROCEDURA')

ALTE

lcProcFile = '"' + lcProcFile + '"'

SETĂ PROCEDURA LA ADITIVUL &lcProcFile

ENDIF

ENDIF

Adăugarea codului de metodă la coloanele grilei

În capitolul 6, am prezentat o clasă grilă cu anteturi multilinie. Utilizarea clasei este foarte costisitoare, deoarece trebuie adăugat o mulțime de cod la instanță pentru ca aceasta să funcționeze corect. Pentru a facilita implementarea, am adăugat un mic cod la generatorul nostru de grile, astfel încât să adauge codul necesar la coloanele grilei în momentul proiectării. Acest cod, în butonul OK al constructorului, a eliminat necesitatea de a adăuga manual cod la metoda Mutate și Redimensionare a fiecărei coloane:

*** OK, vedeți acum dacă folosim o grilă de antet dinamică cu mai multe linii

*** Dacă da, solicitați utilizatorului să vadă dacă codul ar trebui să fie scris în

*** metodele de mutare și redimensionare a coloanei

IF LOWER( wbaControl[1].class ) = 'grdmlheaders'

IF MESSAGEBOX( 'Doriți să adăugați codul necesar' + chr( 13 ) + ;

'la coloanele grilei de păstrat' + chr( 13 ) + ;

„antetele cu mai multe linii sunt poziționate corect?”;

, 4 + 32, „Adăugați codul acum?” )

6

PENTRU FIECARE loColumn ÎN wbaControl[1].columns

loColumn.WriteMethod('Moved', 'Column::Moved()' + CHR( 13 ) + ;

„This.Parent.RefreshHeaders()” + CHR( 13 ) + ;

„NODEFAULT” )

loColumn.WriteMethod('Resize', 'Column::Moved()' + CHR.( 13 ) + ;

„This.Parent.RefreshHeaders()” + CHR( 13 ) + ;

„NODEFAULT” )

ENDFOR

ENDIF

ENDIF

Dacă s-ar întâmpla să întâmpinați mici ciudatenii atunci când utilizați generatorul nostru de grile, rețineți că acestea sunt mai probabil să fie ciudații ale generatorului de grile nativ Visual FoxPro. Singura dată când am experimentat ceva ieșit din comun este atunci când am adăugat, eliminat și reordonat coloane în mod repetat într-o singură sesiune de constructor. Este posibil să faci și tu. Dacă puteți găsi motivele acestor anomalii examinând GridBldr.vcx::GridBldr (constructorul nativ de rețea), vă rugăm să ne trimiteți un e-mail cu soluția. O privire la codul sursă și veți înțelege de ce nu am avut nici timp, nici răbdare să investigăm mai departe.
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Catalog catalog (Exemplu: vcxlist.scx)

Scopul VCXList este de a citi conținutul unui fișier proiect specificat și de a construi un tabel care conține detaliile tuturor claselor vizuale utilizate în acel proiect. Este extrem de simplu de utilizat, doar invocați formularul, selectați proiectul și apăsați butonul „Go”.

Un nou tabel va fi creat în directorul principal al proiectului, denumit vcxlist.dbf cu următoarea structură:

CCLASLIB C ( 60,0 ) && Numele bibliotecii de clasă

CCIASNAME C ( 35,0 ) && Numele clasei

CBASECLAS C (25,0 ) && Clasa de bază VFP

CPARENT C ( 50,0 ) && Biblioteca și numele clasei părinte

CDESC C (150,0 ) && Descrierea clasei

Acest tabel este folosit și de utilitarul nostru „MC.PRG” (vezi mai jos).

Jÿ Creați proiect

Proiect: |CH06.PJX

în Polder: CWFP60ÌCH06

frmsample 	formSample formular clasă
cmdbase 	commandbuttonButonul de comandă de bază
cbobase 	comboboxBase Drop Down Combo Clas
cboqfill 	ch06::cbobaseUmplere rapidă Searct
grdbigheaders 	ch06::grdbaseMulit anteturi grilă de linii într-o statistică
edtbase 	editbox caseta de editare care se extinde și shrir |
igrdmlheaders 	ch06::grdbaseh eade rs th at sc ro 11 sho rizo n at¿
txtbase 	textboxbase clasa text casetaI
txtgrdnextrow 	ch06::txtgridSe mută în aceeași coloană în următoarea
txtsearchgrid 	ch06::txtgrid	
caseta de selectare 	chkdisabled	
|grdbase 	gridBase grid class - highlights cui |

Ieșire din clasa selectată de modificare	

Figura 12.8 Catalog Catalog - vcxlist.scx

În timp ce aveți acest formular deschis, puteți deschide, de asemenea, designerul de clasă pentru orice clasă, selectând pur și simplu clasa în caseta cu listă și făcând clic pe butonul „Modificați clasa selectată”.

Ce face VCXList

Acest formular își face toată munca în metoda personalizată SetUp. În primul rând, metoda citește numele proiectului selectat și schimbă directorul implicit cu cel al proiectului. Dacă se găsește un tabel numit vcxust.cbf, acesta este deschis exclusiv și șters. În caz contrar, un nou tabel este creat în directorul principal al proiectului. Acest tabel trebuie să fie localizat acolo deoarece toate căile stocate în fișierul de proiect sunt relative la directorul principal al proiectului. Dacă acesta nu este și directorul implicit, atunci deschiderea bibliotecilor de clasă poate fi problematică.

Fișierul de proiect este apoi deschis ca DBF și o matrice locală este populată din câmpul de nume al proiectului pentru toate intrările al căror TYPE = "V" (Visual Class Library). Apoi, pentru fiecare bibliotecă de clase identificată, funcția nativă AVCXCLASSES() este utilizată pentru a prelua detaliile claselor pe care le conține și pentru a insera datele în tabel.

În cele din urmă, caseta listă este populată (prin metoda personalizată Updlist) și formularul este gata pentru utilizare imediată pentru a oferi acces rapid la orice clasă utilizată în proiect. Deși acest lucru este destul de util în sine, scopul real al acestui utilitar este de a crea tabelul vcxlist.
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Un wrapper pentru „modificarea clasei” (Exemplu:mc.prg)

Acest mic program a fost conceput inițial de Steven Black, când lucram cu toții la un proiect foarte mare la începutul anului 1999. Problema cu care ne-am confruntat a fost că existau un număr mare de biblioteci de clasă și să ne amintim care bibliotecă avea ce clasă era dificil. Scopul MC.PRG este de a simplifica sarcina de a deschide o anumită clasă pentru modificare prin utilizarea unui tabel pentru a stoca detaliile necesare pentru toate clasele. Această încarnare a programului folosește tabelul vcxlist.dbf, care a fost descris în secțiunea precedentă.

Pentru a deschide designerul clasei, trebuie doar să apelați mc, ca funcție cu numele clasei necesare:

MC ( <numele clasei> )

Puteți chiar să specificați o metodă de modificat, astfel încât atunci când designerul se deschide, fereastra de cod a acelei metode să fie deschisă pentru editare.

MC( <numele clasei>, <numele metodei> )

Iată codul programului:

**************************************************** ********************

* 	Program. MC.PRG

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Acest program a fost conceput și scris inițial de Steven Black

* 	...........: în timp ce lucram cu toții împreună la un proiect major la începutul anului 1999.

* 	...........: Dorim să recunoaștem acest lucru și toate contribuțiile lui Steven,

* 	..........:și să-i mulțumesc pentru disponibilitatea de a-și împărtăși ingeniozitatea

* 	..........:și cunoștințe cu noi ceilalți.

* 	Sintaxă.....: MC( <clasă>[,<methodname>]) sau

* 	..........:DO MC CU <nume clasă>[,<nume metodă>]

LPARAMETERS tcClass, tcMethod

LOCAL lcClass, lnSelect, lcOrigDir, lcOldError, lcLoc, lcMethod *** Trebuie să treacă cel puțin un nume de clasă!

IF VARTYPE(tcClass) # "C" SAU EMPTY(tcClass)

ÎNTOARCERE

ALTE

*** Obțineți numele clasei

lcClass = LOWER( ALLTRIM( tcClass ))

ENDIF

*** Salvați zona de lucru curentă

lnSelect= SELECT()

*** Deschideți tabelul VCXList

DACĂ ! UTILIZAT ("VcxList")

*** Dezactivați temporar gestionarea erorilor

lcOldError = ON("EROARE")

LA EROARE *

IcLoc = " "

*** Localizați tabelul VCXList de utilizat

IcLoc = LOCFILE( „VCXList”, „DBF”, „Unde este” )

*** Restabiliți gestionarea erorilor și verificați rezultatul

ON ERROR &lcOldError

DACĂ ! EMPTY(lcLoc) ȘI „vcxlist” $ LOWER(lcLoc)

*** OK - Deschideți tabelul

UTILIZAȚI (lcLoc) DIN NOU ÎMPĂRȚIT ÎN 0

ALTE

*** Nelocalizat - Anulare

WAIT WINDOW „Nu se poate localiza VCXList.DBF - Se anulează”

ÎNTOARCERE

ENDIF

ENDIF

*** Selectați VCXList

SELECTAȚI Lista VCXL

*** Faceți ca VCXList Locația să fie curentă implicită deoarece

*** classlib-urile sunt salvate cu căi relative

*** către locația proiectului (și, prin urmare, către VCXList)!

lcOrigDir = FULLPATH( CURDIR() )

SETAT IMPLICIT LA JUSTPATH(DBF())

*** Am primit și un nume de metodă?

DACĂ VARTYPE(tcMethod) = "C" ȘI ! EMPTY(tcMethod)

lcMethod= "Metoda" + tcMethod

ALTE

lcMethod= ''

ENDIF

*** Găsiți clasa necesară

LOCATE FOR ALLTRIM(cclasname) == lcClass

DACA ESTE GASIT()

*** Afișați numele VCX

WAIT WINDOW „Deschiderea bibliotecii de clasă:” + ALLTRIM(cClasLib) ASTEPTĂ ACUM

CLASA MODI (ALLTRIM(cClasName)) din (ALLTRIM(cClasLib)) &lcMethod ACUM Așteptați

ALTE

Așteptați fereastra „Class” + lcClass + „Nu a fost găsit” ACUM Așteptați

ENDIF

*** Restaurați locația inițială și zona de lucru

SETARE IMPLICIT LA (lcOrigDir)

SELECTARE (lnSelect)

Codul în sine este destul de simplu. Singurul lucru de remarcat este utilizarea funcției locfileo pentru a găsi tabelul vcxlist.dbf. Din câte putem spune, este o caracteristică complet nedocumentată a LOCFILE() că atunci când este utilizat pentru a localiza un fișier, calea fișierului este adăugată automat la calea de căutare curentă VFP. (Acest lucru este valabil în toate versiunile de Visual FoxPro.)

Aceasta înseamnă că odată ce ați identificat locul în care se află tabelul, directorul este adăugat la calea de căutare curentă și toate apelurile ulterioare către MC vor găsi tabelul. Desigur, dacă lucrați la mai multe proiecte, aceasta ar putea fi o problemă și poate preferați să înlocuiți locfileo cu un simplu getfile() care nu vă modifică calea de căutare. Cu toate acestea, considerăm că, deoarece majoritatea dintre noi lucrăm la un singur proiect la un moment dat, adăugarea locației vcxust.cbf la calea de căutare este o economie de timp utilă.
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Un utilitar de documentare a bibliotecii de formulare/clase (Exemplu: genscode. scx)

Unul dintre multele lucruri care s-au schimbat odată cu introducerea Visual FoxPro Versiunea 3.0 a fost că a devenit mai dificilă vizualizarea codului pentru formulare. Acest lucru se datorează faptului că în loc să se producă un program fde pentru un ecran, tot codul a fost stocat în câmpurile memo din tabelul care definește formularul. O strategie similară a fost adoptată și pentru bibliotecile de clasă. Vrăjitorul de documentație inclus cu Visual FoxPro și opțiunea „export cod” furnizată cu browserul de clasă sunt ambele utile. Cu toate acestea, am simțit în continuare nevoia unui utilitar simplu pentru a documenta toate proprietățile și metodele unui formular și pentru a documenta fie o singură clasă, fie o întreagă bibliotecă de clasă. Cod gens. SCX este rezultatul.

Figura 12.9 Genscode.scx: Form/VCXDocumenter

Când se selectează un formular sau o bibliotecă de clase și se face clic pe butonul „Previzualizare” sau „Imprimare”, metoda WriteCode personalizată a formularului este apelată pentru a produce rezultatul ca fișier text care este fie deschis pentru vizualizare pe ecran, fie trimis direct la imprimanta. Fișierul text nu este salvat în mod implicit, așa că dacă trebuie să creați o înregistrare permanentă, utilizați opțiunea de previzualizare și utilizați opțiunea standard de meniu „Salvare ca” pentru a salva fișierul sub un nume nou. Iată codul care produce de fapt documentația, care este conținut în metoda WriteCode.

Mai întâi definim câteva constante și deschidem fișierele sursă și destinație:

LOCAL ARRAY laText[1]

LOCAL IcSource, IcTarget, InFno, InOldMemo, InNumLine, lnCnt, IcText, IcClassName

*** Anunță

wait window nowait „Se generează codul sursă...”

*** printează constantele proprietății

#DEFINE CRLF CHR(13)+CHR(10)

#DEFINE LOC_USER „***** DEFINIT DE UTILIZATOR *****” + CRLF

#DEFINE LOC_PROP '***** PROPERTIES *****' + CRLF

#DEFINE LOC_METH '***** METHODS *****' + CRLF

#DEFINE LOC_LINE REPLICATE('=',SET('MEMOWIDTH'))

*** Extrageți numele fișierului sursă

IcSource

THISFORM.txtSource.Value

lcTarget = THISFORM.cOutputName

*** Asigurați-vă că fișierul țintă nu există

IF FILE(lcTarget)

ȘTERGE FIȘIER (lcTarget)

ENDIF

*** Deschideți fișierul țintă pentru scriere

lnFno = FCREATE(lcTarget)

*** Scrieți informații despre antet

lcText = 'FIȘIER SURSA: ' +UPPER(ALLTRIM(lcSource))

FPUTS(lnFno,lcText)

FPUTS(lnFno,LOC_LINE)

lcText = „Documentat: „+TTOC(DATETIME()) + CRLF

FPUTS(lnFno,lcText)

Detaliile reale sunt adunate folosind funcția ALINES() pentru a citi conținutul câmpurilor memo într-o matrice locală și apoi scrise linie cu linie în fișierul text destinație. Un bloc de antet standard este scris mai întâi pentru fiecare obiect sau clasă nouă care este întâlnită. În continuare, orice proprietăți sau metode definite de utilizator sunt scrise (din câmpul Rezervat3) și apoi este scris conținutul câmpurilor de proprietăți și metode. Odată ce se ajunge la sfârșitul fișierului sursă, fișierul de ieșire este închis, astfel încât să poată fi vizualizat sau imprimat după cum este necesar.

*** Scrieți detalii (prin trecerea în buclă prin VCX)

SELECTAȚI vcx

SCANĂ

*** Ignorați informațiile despre font / versiunile vechi etc.

DACĂ GOL (marca temporală) SAU ȘTERS ()

BUCLĂ

ENDIF

*** Obțineți numele clasei

lcClassName = ALLTRIM(objname)

DACĂ Thisform.cboSelectClass.ListIndex > 1

*** Ignorați cursurile dacă nu este necesar

DACĂ ! (SUPER(ALLTRIM(lcClassName)) == ;

SUS (ALLTRIM(Thisform.cboSelectClass.DisplayValue)))

BUCLĂ

ENDIF

ENDIF

*** Antetul obiectului

FPUTS(lnFno,PADR('Nume ',17,'.') + ' ' + UPPER(ALLTRIM(nume obiect)) )

FPUTS(lnFno,PADR('Clasa ',17,'.') + ' ' + UPPER(ALLTRIM(clasa)) )

FPUTS(lnFno,PADR('Parinte',17,'.') + ' ' + UPPER(ALLTRIM(parent)) )

FPUTS(lnFno,PADR('Clasa de bază',17,'.') + ' ' + UPPER(ALLTRIM(clasa de bază)) )

FPUTS(lnFno,PADR('Descriere',17,'.') + ' ' + UPPER(ALLTRIM(rezervat7)) + CRLF)

*** Elemente definite de utilizator

IF !EMPTY(rezervat3)

DIMENSION laText[1]

laText

lnNumLine = ALINES( laText, rezervat3)

FPUTS(lnFno,LOC_USER)

FOR lnCnt = 1 TO lnNumLine

lcText = laText[ lnCnt ]

FACE CAZ

CASE ISBLANK(lcText)

lcText = ''

CASE LEFT(lcText,1) = '*'

lcText = 'Metodă: ' + SUBSTR(lcText,2)

IN CAZ CONTRAR

lcText = 'Proprietate: ' + lcText

ENDCASE

IF !EMPTY(lcText)

FPUTS(lnFno,lcText)

ENDIF

URMĂTORUL

FPUTS(lnFno, LOC_LINE + CRLF)

ENDIF

*** Proprietăți

IF !EMPTY(proprietăți)

DIMENSION laText[1]

laText = ""

lnNumLine = ALINES( laText, proprietăți)

FPUTS(lnFno,LOC_PROP)

FOR lnCnt = 1 TO lnNumLine

lcText = laText[ lnCnt ]

FPUTS(lnFno,lcText)

URMĂTORUL

FPUTS(lnFno, LOC_LINE + CRLF)

ENDIF

*** Metode

IF !EMPTY(metode)

DIMENSION laText[1]

laText = ""

lnNumLine = ALINES( laText, metode)

FPUTS(lnFno,LOC_METH)

FOR lnCnt = 1 TO lnNumLine

lcText = laText[ lnCnt ]

FACE CAZ

CAZUL SUS(STÂNGA(lcText,9)) = „PROCEDURĂ”

lcText = '*** '+UPPER(ALLTRIM(SUBSTR(lcText,10))) + 'METODA'

CAZ SUS(STÂNGA(lcText,7)) = „ENDPROC”

lcText = LOC_LINE + CRLF

CASE ISBLANK(lcText)

lcText = ''

ENDCASE

IF !EMPTY(lcText)

FPUTS(lnFno,lcText)

ENDIF

URMĂTORUL

ENDIF

ENDSCAN

*** Tidy-up - închideți fișierul de ieșire

FCLOSE(lnFno)

*** Mesaje clare

Așteptați clar
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Share.prg - un program de completare pentru browser de clasă

Acest instrument foarte util a fost creat de Steven Black și este disponibil pentru descărcare gratuită de pe site-ul său web la www.stevenblack.com. Funcția sa este de a lua o singură clasă și de a o copia într-o nouă bibliotecă de clase. Cu toate acestea, nu numai că extrage clasa specificată, ci va determina și copia toate clasele din ierarhia de moștenire a clasei specificate în noua bibliotecă. Rezultatul este că noua dvs. bibliotecă va conține toate clasele necesare pentru a utiliza clasa selectată fără a fi necesar să furnizeze un set complet de biblioteci de clase.



Figura 12.10 (mai jos) arată rezultatul utilizării acestui utilitar pentru a extrage toate clasele necesare pentru o clasă complexă compozită dintr-o bibliotecă „appelass”. După cum puteți vedea, noul VCX a inclus toate ierarhiile de clasă pentru toate controalele utilizate, chiar dacă acestea sunt de fapt definite în mai multe biblioteci diferite:

¡JJ (c:\vfp60\calendr.vcx)

B- Obiecte

ω (e: \newaquaMibs\appclass. vc:· |

[51 ebogrid

H «acntaddsess

[51 «acntaddttl

[5] acntcalendar

O acntcsehdr

F-[5] « aentgetvenue

1 e acntgetvenueyear

[51 «aentnameentry

H aentpersoana

[51 «acntpostaladd

H acntrungetqa

[51 «aentssesiune

[51 actntstuhdr

..aqrymgr

Calendai Control - populate forro uRetVal | cu șir delimitat prin virgulă oí date

Obiecte

61 	:

è 	:

shpctls [ShapeJ shphdr [ShapeJ Iblselmth [Label] ebomth [ComboBox] spnyear [S pinner) Iblselyear [Label] chkdayOI [CheckB ox) chkmon (CheckB ox) chktue [CheckB ox) chkwed] (CheckB ox)

chksat [CheckBox] chksun (CheckB ox)

Clasa: acntcalendar 	A

Clasa de bază: Container

Marcaj orar: 29/05/9810:48:05 AM

xcbostd

□·· H xchk BE] xchkstd

L И xchkstdpict

□·· □ xcmd

a-g:

..ffi

Calendar Control - completați formularul uRetVal * |

cu șir de date delimitat prin virgulă

shpctls [ShapeJ shphdr [ShapeJ Iblselmth [Etichetă] ebomth (ComboBox) spnyear (Spinner) Iblselyear [Label] chkdayOI (CheckBox) chkmon (CheckBox] chktue [CheckBox] chkwed (CheckB o CheckB o CheckB) la ( CheckBox) chksun (CheckB ox)

Clasa: acntcalendar 	A

Clasa de bază: Container

Marcaj orar: 01/02/0008:41:02AM

H

H

Figura 12.10 Rezultate produse de Share.prg Class Browser add-ln

Pentru a utiliza acest utilitar, mai întâi trebuie să înregistrați programul ca program de completare Class Browser. Pentru a face acest lucru, mai întâi copiați programul share.prg în același director în care se află browser.app și browser.dbf (în mod normal, directorul principal VFP). Apoi, deschideți Class Browser pentru a crea referința la obiectul sistemului pentru browser ("oBrowser") și din fereastra de comandă caliți metoda „Addlri” a browserului, după cum urmează:

_oBrowser.Addin( „Extractor de clasă”, „share.prg” )

E tot ce este. Acum puteți deschide orice bibliotecă de clasă în browser și când deschideți meniul cu clic dreapta, „Extractor de clasă” va fi disponibil prin opțiunea „Suplimente”. (Amintiți-vă că Browser-ul clasei are două meniuri de comenzi rapide diferite, în funcție de locul în care faceți clic. Opțiunea Add-Ins se află în meniul principal de comenzi rapide ale Browser-ului și nu este disponibilă în meniul Clasă care apare când faceți clic dreapta în oricare dintre detaliu principal Windows.) Este greu de supraestimat utilitatea acestui mic instrument și chiar dacă nu utilizați browserul de clasă pentru nimic altceva, acesta ar trebui să facă parte cu siguranță din setul dvs. de instrumente standard.
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Un instrument de căutare mai bun (Exemplu: Finder. scx)

Ați avut vreodată nevoie să știți toate locurile dintr-o aplicație în care a fost folosit un anumit tabel? Sau ce zici de toate formularele care conțin o instanță a unei clase specifice? Găsitorul nostru mai bun face ca aceasta să fie într-adevăr o muncă foarte ușoară. Tot ce trebuie să faceți este să introduceți șirul de căutare și să selectați directorul pentru a căuta. Formularul completează apoi caseta combinată de tipuri de fișiere cu tipurile de fișiere valide găsite în directorul specificat. Listele „Fișiere de căutat” și „Nume câmpuri de căutat” sunt populate corespunzător atunci când este selectat un nou tip de fișier. După ce ați selectat unul sau mai multe fișiere și ați specificat cel puțin un câmp de căutat, apăsați butonul Go, iar formularul afișează rezultatele pe pagina următoare.

Figura 12.11 Finder.scx: Căutarea claselor forali care au o metodă de configurare

Directoarele de căutat sunt plasate în proprietatea personalizată aDirectories a formularului prin metoda personalizată SetDirectories. De asemenea, repopulează casetele combo și listă apelând metoda personalizată GetFileTypes a formularului:

DACĂ ! GOL ( .cDirectory )

*** Verificați tipurile de fișiere din directorul selectat

*** Adăugați ceea ce este disponibil în caseta combinată de tipuri de fișiere

.GetFileTypes( .cDirectory )

*** Vedeți dacă trebuie să recurgem prin directorul selectat

DACA .Irecurse

.GetChildDirectories( .cDirectory )

ENDIF

ENDIF

Acest cod din metoda personalizată GetChildDirectories umple matricea cu calea complet calificată a tuturor subdirectoarelor din arbore:

LPARAMETERS tcDirectory

LOCAL lnDirCnt, laDirs[1], lnCnt, lnLen

DACĂ ! ( tcDirectory == Thisform. cDirectory )

*** adăugați directorul curent la listă dacă nu este rădăcină

lnLen = ALEN( Acest formular. aDirectoare) + 1

DIMENSIUNE Thisform.aDirectories[ lnLen ]

Thisform.aDirectories [ lnLen ] = tcDirectory

*** vedem dacă trebuie să adăugăm noi tipuri de fișiere

Thisform.GetFileTypes( tcDirectory )

ENDIF

*** Acum vedeți dacă avem directoare în directorul curent

lnDirCnt = ADIR(laDirs, tcDirectory + '*.*', 'D' )

DACĂ LnDirCnt > 1

FOR lnCnt = 1 TO lnDirCnt

IF LEFT( laDirs[ lnCnt, 1 ], 1 ) # '.'

*** Asigurați-vă că avem un director și nu un fișier

IF DIRECTORY( tcDirectory + laDirs[ lnCnt, 1 ] )

Thisform.GetChildDirectories( tcDirectory + laDirs[ lnCnt, 1 ] + '\')

ENDIF

ENDIF

ENDFOR

ENDIF

Metoda GetFileTypes folosește intrările din tabelul FinderTypes.dbf pentru a determina ce tipuri de fișiere trebuie incluse în caseta combinată. Acesta examinează extensia fiecărui fișier din directorul specificat și o adaugă la matricea aFileTypes a formularului dacă poate fi găsit în FinderTypes.dbf și nu este încă membru al matricei:

LOCAL lnFileCount, laFiles[ 1 ], lnFile, lcExtension, lnSelect, lnLen

lnSelect = SELECT ()

lnFileCount = ADIR( laFiles, tcDirectory + '*.*' )

DACĂ lnFileCount > 0

PENTRU lnFile = 1 TO lnFileCount

lcExtension = UPPER( ALLTRIM( JUSTEXT( laFiles[ lnFile, 1 ] ) ) )

*** Vedeți dacă aceasta este o extensie de fișier „legală”.

SELECTați FinderTypes

LOCATE FOR ALLTRIM( FinderTypes.cExtension ) = lcExtension

DACĂ ! GĂSITE()

BUCLĂ

ENDIF

*** Întindere legală... vezi dacă o avem deja în matrice

IF ASCAN( Thisform.aFileTypes, FinderTypes.cAbbr ) = 0

*** Dacă acesta este primul tip de fișier găsit,

*** înlocuiți intrarea „(niciun)” cu care a fost inițializată combo-ul

lnLen = ALEN( Thisform.aFileTypes, 1 )

IF lnLen = 1 AND Thisform.aFileTypes[ 1, 1] = ' (Niciuna) '

ALTE

lnLen = lnLen + 1

DIMENSIUNE Thisform.aFileTypes[ lnLen, 2 ]

ENDIF

*** Adăugați acest tip de fișier în listă

Thisform.aFileTypes[ lnLen, 1 ] = FinderTypes.cAbbr

Thisform.aFileTypes[ lnLen, 2 ] = FinderTypes.cExtension

ENDIF

ENDFOR

ENDIF

SELECTARE ( lnSelect )

De fiecare dată când se face o selecție în caseta combinată, metoda GetFileNames a formularului este invocată pentru a repopula caseta cu listă de fișiere de căutat:

LOCAL lnfile, lnFileCnt, lnDirCnt, lnDir, laFiles[1], lnTotalFiles, lcFileType

lnTotalFiles = 0

*** Dacă avem doar „(niciunul)” ca tip de fișier, nu faceți nimic

IF EMPTY( Thisform.cFileType )

ÎNTOARCERE

ALTE

lcFileType = UPPER( alltrim( Thisform.cFileType ) )

ENDIF

lnDirCnt = ALEN( Thisform. aDirectories )

FOR lnDir = 1 TO lnDirCnt

*** Obțineți toate fișierele din directorul curent

lnFileCnt = ADIR( laFiles, Thisform.aDirectories[ lnDir ] + '*.*' )

*** Parcurgeți fișierele și adăugați-le pe cele de tipul corect în matrice

*** Coloana 1 este numele fișierului, iar coloana 2 este directorul în care se află

FOR lnFile = 1 TO lnFileCnt

IF UPPER( ALLTRIM( JUSTEXT( laFiles[ lnFile, 1 ] ) ) ) == lcFileType

lnTotalFiles = lnTotalFiles + 1

DIMENSIUNE Thisform.aFileNames[ lnTotalFiles, 2 ]

Thisform.aFileNames[ lnTotalFiles, 1 ] = JUSTSTEM( laFiles[ lnFile, 1 ] )

Thisform.aFileNames[ lnTotalFiles, 2 ] = Thisform.aDirectories[ lnDir ]

ENDIF

ENDFOR

ENDFOR

*** Sortați numele fișierelor

ASORTARE( Thisform.aFileNames, 1 )

Metoda GetFieldNames a formularului este apoi utilizată pentru a repopula câmpurile pentru a căuta caseta de listă:

LOCAL lcExtension, lnSelect, lnFld, lnFldCnt, lcFile, laFields[ 1 ]

lnSelect = SELECT ()

lcExtension = UPPER( ALLTRIM( Thisform.cFileType ) )

*** Vezi ce fel de dosar avem

SELECTați FinderTypes

LOCATE FOR ALLTRIM( FinderTypes.cExtension ) == IcExtension

DACA ESTE GASIT ()

*** Este un fișier text, așa că nu putem selecta niciun câmp

IF FinderTypes.lIsText

DIMENSIUNE ThisForm.aFieldNames[ 1 ]

Thisform.aFieldNames [ 1 ] = ''

ALTE

*** Este o structură standard, cum ar fi un pjx, scx, vcx etc.

*** Introduceți structura sa în matricea aFieldNames și reîmprospătați caseta cu listă

IF FinderTypes.lStatic

lcFile = ALLTRIM( Thisform.aFileNames[ 1, 1 ] )

SELECTARE 0

USE ( Thisform.aFileNames[ 1, 2 ] + lcFile + '.' + lcExtension ) ;

DIN NOU NOUPDATE

lnFldCnt = AFIELDS( laFields )

UTILIZARE

DIMENSIUNE Thisform.aFieldNames[ lnFldCnt ]

PENTRU lnFld = 1 LA lnFldCnt

Thisform.aFieldNames[ lnFld ] = laFields[ lnFld, 1 ]

ENDFOR

ALTE

*** Tipul de fișier selectat este dbf

Thisform.GetDBFFields()

ENDIF

ENDIF

ENDIF

SELECTARE ( lnSelect )

Metoda de căutare personalizată a formularului se rotește prin fiecare fișier selectat, căutând o potrivire pentru șirul de căutare specificat în câmpurile selectate. Când se găsește o potrivire, o înregistrare este inserată într-un cursor, astfel încât rezultatele căutării să poată fi afișate în grila de pe a doua pagină.

Caută Gritería

^JnjA

Rezultate

Cale: IC:\PROGRAM FILES\MICROSOFTOFFICEtOFFICEWFPTIPStCH05\CBOGRIC

Fișier: I CBOGRID.VCX

|Nume fișier/obiect 	|Câmp # 			Rec.Ж V
P acbogrid 		1METODE	
	timp de petrecere			
	txtnumeric2METHODS	
	Istlookup3METODE	
	cbolookup4METODE	
	txlnumeric5METODE	
	spntime6METODE	
	updres7METODE	
				
				
				
				
				

Moditate

Ieșire tipărire	

rezultate: o listă a tuturor claselor care au o metodă de configurare

Figura 12.12 Căutare

Cea mai mare parte a muncii este realizată în metoda personalizată SearchTextFile dacă fișierul ales este un fișier text și în metoda personalizată SearchTable dacă este un formular, o clasă sau o altă entitate bazată pe tabel. Făcând clic pe butonul мошку, vă permite să editați formularul, clasa, raportul etc. chiar din pagina de rezultate.
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Concluzie

După cum sa menționat în introducerea acestui capitol, aceste instrumente sunt destinate dezvoltatorilor să le utilizeze și nu sunt oferite ca „complete și pregătite pentru producție”. Vă rugăm să nu vă supărați dacă descoperiți o eroare și nu ezitați să modificați sau să extindeți oricare dintre aceste instrumente pentru a vă convinge. Ne-ar plăcea să auzim despre orice probleme majore pe care le găsiți și despre orice direcții noi pe care vi le pot sugera aceste exemple.

Copyright 2000 de către Marcia Akins, Andy Kramek și Rick Schummer Toate drepturile rezervate

Capitolul 13 - Lucruri diverse

"Există trei căi către ruină: femeile, jocurile de noroc și tehnicienii. Cel mai plăcut este cu femeile, cel mai rapid este cu jocurile de noroc, dar cel mai sigur este cu tehnicienii." (Georges Pompidou, președinte francez. Citat în „Sunday Telegraph,” Londra, 26 mai 1968).

Acest capitol conține o gamă largă de sfaturi utile și utilități care nu aparțin cu adevărat unui loc, dar care pot fi utile în mod propriu din când în când. Bucurați-vă!
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Utilizarea depanatorului Visual FoxPro

Depanatorul Visual FoxPro, în forma care a fost introdusă pentru prima dată în versiunea 5.0, este un set foarte puternic de instrumente care poate fi de o valoare enormă atunci când testează codul. Cu toate acestea, este, de asemenea, un instrument destul de complex și poate dura ceva timp pentru a vă obișnui.

Copyright 2000 de către Marcia Akins, Andy Kramek și Rick Schummer Toate drepturile rezervate

Caracteristicile depanatorului Windows

Fiecare dintre ferestrele disponibile în depanator are o caracteristică interesantă care poate să nu fie evidente. Iată câteva dintre lucrurile pe care le-am adunat despre ele:

Fereastra localnicilor

• 	Puteți modifica valoarea unei variabile locale sau a unei proprietăți făcând clic în coloana cu valori a ferestrei și introducând o nouă valoare. Astfel de modificări vor fi păstrate atâta timp cât variabila sau proprietatea rămâne în domeniul de aplicare

• 	Făcând clic dreapta se afișează un meniu de comenzi rapide care vă permite să comutați starea vizibilității și, prin urmare, claritatea afișajului:

ο Variabile publice declarate cu cuvântul cheie PUBLIC

° Variabile locale declarate cu cuvântul cheie LOCAL

° Standard Toate variabilele din domeniul de aplicare al procedurii numite de „Locali pentru”

° Obiecte Referințe obiecte

• 	Puteți explora un obiect sau o matrice făcând clic pe semnul „+” din fereastră

• 	Fereastra Locals poate fi invocată programatic cu ACTIVATE WINDOW LOCALS

Fereastra de ceas

• 	Puteți modifica valoarea unei variabile locale sau a unei proprietăți făcând clic în coloana cu valori a ferestrei și introducând o nouă valoare. Astfel de modificări vor fi păstrate atâta timp cât variabila sau proprietatea rămâne în domeniul de aplicare

• 	Puteți explora un obiect sau o matrice făcând clic pe semnul „+” din fereastră

• 	Puteți trage expresii în și dinspre fereastra de comandă și linia de intrare „Urmărire”.

• 	Puteți trage expresii din fereastra de urmărire direct în linia de intrare „Vizionare”.

• 	Referințele de scurtătură precum This și ThisForm pot fi folosite în expresiile Watch

• 	Pentru a vedea numele oricărui obiect se află sub indicatorul mouse-ului în orice moment, includeți următoarele în lista de expresii de urmărire: „sys(1272, sys(1270))”

• 	Fereastra ceasului poate fi activată programatic cu ACTIVARE WINDOW WATCH

Fereastra de urmărire

• 	Pe lângă opțiunile „Reluare” (triunghi verde) și „Anulare” (cerc roșu), depanatorul oferă patru opțiuni de mișcare atunci când urmărește codul, după cum urmează:

° Pas în: Execută numai linia curentă de cod

° Step Over: Dezactivează urmărirea în timpul executării unei subrutine sau apel la o metodă sau o funcție definită de utilizator

o Step Out: reia execuția procedurii sau metodei curente, dar se suspendă din nou când procedura/metoda este finalizată

o Run to Cursor: reia execuția de la linia curentă și se suspendă când este atinsă linia care conține cursorul

• 	Plasarea cursorului mouse-ului peste o referință de variabilă sau de proprietate afișează o fereastră de tip tooltip care arată valoarea curentă pentru acel element. Puteți limita ceea ce este evaluat prin evidențierea textului în fereastra de urmărire. O utilizare pentru aceasta este verificarea faptului că un obiect este într-adevăr un obiect prin eliminarea unui apel de metodă. De exemplu, trecerea mouse-ului peste „oObj.Init()” nu va afișa nimic, dar dacă evidențiați doar „oObj”, veți primi un sfat cu instrumente care arată „Obiect”. " O altă utilizare este să obțineți valoarea elementelor cuprinse între ghilimele; selectând „toObj.Name” din „ CASE TYPE(”toObj.Name”) =" va afișa valoarea proprietății nume în sfatul cu instrumente.

• 	Opțiunea Setați următoarea instrucțiune: Când sunteți în modul de urmărire, puteți sări blocuri de cod sau să reexecutați codul, pur și simplu deplasând cursorul mouse-ului pe rândul dorit și alegând „Set Next Statement” din meniul „Debug” ( Tastatură: „alt d + n”). În timp ce opțiunea „Run to Cursor” dezactivează temporar urmărirea, dar încă rulează codul, „Set Next Statement” se mută direct în locația specificată fără a executa deloc codul intermediar.

• 	Codul poate fi copiat din fereastra de urmărire și lipit în fereastra de comandă sau într-un program temporar și executat independent fie ca bloc, fie prin evidențierea liniilor și executându-le direct.

• 	Puteți evidenția și trage text direct din urmă în fereastra ceasului.

• 	Fereastra Trace poate fi activată programatic cu ACTIVATE WINDOW TRACE.

Fereastra de depanare

• 	Orice expresie FoxPro validă precedată de comanda debugout este evaluată și transmisă în fereastra de ieșire de depanare. Toate următoarele sunt valide: DEBUGOUT "Hello World", DEBUGOUT DATE(), DEBUGOUT 22/7.

• 	Ieșirea de depanare poate fi activată programatic folosind SET DEBUGOUT TO <fișier> [ADDITIVE] și dezactivată cu SET DEBUGOUT TO.

• 	mesajele assert și orice evenimente care sunt urmărite în instrumentul de urmărire a evenimentelor, sunt, de asemenea, transmise către destinația DebugOut (adică în fișier sau fereastră sau ambele).

• 	Pentru a urmări metode personalizate sau metode native care nu sunt disponibile în instrumentul de urmărire a evenimentelor, includeți instrucțiunile programului de depanare. (Notă: astfel de instrucțiuni nici nu trebuie să fie eliminate. Dacă fereastra de ieșire nu este disponibilă deoarece nu este deschisă sau deoarece programul este executat într-un mediu de rulare, toate comenzile DebugOut sunt pur și simplu ignorate.)

Fereastra DebugOut poate fi activată programatic cu ACTIVATE WINDOW „Debug Output”.

Fereastra CallStack

• 	Activarea „Show Call Stack Order” plasează un număr secvenţial alături de fiecare program în fereastra Call Stack indicând ordinea în care se execută. Din anumite motive, controlul acestei funcții a fost numit „Poziție ordinală” în meniul pop-up care apare când faceți clic dreapta în fereastra Call Stack.

• 	Activarea indicatorului „Call Stack” afișează un triunghi negru la marginea ambelor ferestre Call Stack și Trace ori de câte ori vizualizați un alt program decât cel care se execută în prezent. În fereastra Call Stack acest triunghi indică programul pe care îl vizualizați, în timp ce în fereastra Trace indică linia, în acel program, care se execută.
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Configurarea depanatorului

Configurarea depanatorului este controlată prin dialogul Opțiuni, unde are propria sa filă. Toate setările sunt stocate (ca și toate celelalte opțiuni controlate de acest dialog) în registry Windows.

Ce cadru sa folosesti?

Depanatorul poate fi rulat fie în propriul „cadru”, ceea ce îl face o aplicație separată, fie în „cadru” FoxPro, caz în care devine un set de ferestre individuale care sunt disponibile din meniul de instrumente și care plutesc peste desktop. Principalele beneficii ale utilizării cadrului de depanare sunt că nu ocupă spațiu prețios pe ecran de la orice rulați, toate ferestrele de depanare sunt conținute într-o singură fereastră de nivel superior și sunt ușor accesibile, iar opțiunea „Remediare” funcționează. Principalul dezavantaj al utilizării cadrului de depanare este că, dacă aveți cod în evenimentele LostFocus sau Deactivate, acel cod va fi declanșat când treceți la și de la depanator și poate interfera cu orice încercați să depanați.

Configurarea ferestrelor de depanare

Opțiunile implicite de configurare ale depanatorului pot fi găsite în dialogul Opțiuni Visual FoxPro (accesibil din panoul Instrumente din meniul principal) unde au propria filă. Cu toate acestea, interfața pentru această pagină nu este standard și nu este imediat evident că elementele disponibile pentru configurare depind de fereastra specificată de butonul de opțiune din secțiunea „Specificați fereastra”, după cum urmează:

Tabelul 13.1 Opțiuni de configurare a ferestrei de depanare

Opțiuni ferestre	
pentru stiva de apeluri 	Comanda stivă de apeluri Indicator de linie curentă Indicator de stivă de apeluri
Font și culori pentru localnici	
Ieșire 	font și culori Înregistrați ieșirea în fișier (specificați fișierul implicit)
Urmărirea 	fontului și a culorilor Afișează numerele de linii

Rețineți că, pentru ca fereastra Call Stack să fie disponibilă în depanator, aveți nevoie ca „Urmărirea între punctele de întrerupere” să fie activată, dar această opțiune se află, util, sub opțiunile „Urmărire fereastră”. Cu toate acestea, cu excepția cazului în care inspectați în mod activ stiva de apeluri, vă recomandăm insistent să păstrați această fereastră închisă. Este cea mai lentă fereastră de depanare pentru reîmprospătare în timp ce parcurgeți codul.

De fapt, setarea „Urmărire între pauze” este factorul principal în determinarea impactului menținerii deschise a depanatorului în timpul rulării codului. Preferăm să-l lăsăm dezactivat în mod implicit, setându-l doar din meniul de comenzi rapide din depanator atunci când este necesar.

Închideți Windows de depanare de care nu aveți nevoie!

Cu cât ai mai multe ferestre de depanare deschise, cu atât este mai mare impactul asupra timpului de execuție a codului tău. Este demn de remarcat faptul că, atunci când rulați depanatorul în „cadru de depanare”, de fapt nu trebuie să aveți nici una dintre ferestrele individuale de depanare deschise, atâta timp cât cadrul în sine este activ. Dacă ați definit și activat punctele de întrerupere necesare, (inclusiv cele definite în fereastra de urmărire), punctele de întrerupere se vor declanșa în continuare conform așteptărilor. Aceasta înseamnă că vă puteți rula codul cu minimul absolut de încetinire.
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Stabilirea punctelor de întrerupere

Visual FoxPro permite patru tipuri de puncte de întrerupere, după cum se arată în tabelul următor. Principala diferență este că punctele de întrerupere bazate pe o locație opresc execuția înainte de executarea liniei de cod, în timp ce cele bazate pe expresii au efect după ce linia de cod a fost executată.

Tabelul 13.2 Tipuri de puncte de întrerupere

Tipul punctului de întrerupere 	are efect
La locație 	Imediat înainte ca linia de cod să fie executată
La locație Dacă expresia este adevărată 	Imediat înainte ca linia de cod să fie executată dacă condiția este îndeplinită
Când expresia este adevărată 	Imediat după linia de cod care a făcut ca expresia să devină adevărată
Când expresia este schimbată 	Imediat după linia de cod care a determinat schimbarea expresiei

Există multe moduri de a seta puncte de întrerupere în depanator. Iată câteva pe care ni le considerăm cele mai utile:

• 	Faceți clic dreapta pe o linie de cod în timp ce editați codul metodei în designerul de formulare sau de clasă sau într-un PRG și alegeți „Setare punct de întrerupere” (se aplică pentru versiunea 6.0 cu pachetul de servicii 3). Aceasta setează un punct de întrerupere „pauză la locație”.

• 	În fereastra de urmărire, puteți selecta orice linie de cod, apoi faceți clic dreapta - Run To Cursor. Acesta este un punct de întrerupere rapidă care este foarte util pentru, de exemplu, oprirea după ce o buclă se termină sau la un alt punct imediat fără a seta un punct de întrerupere permanent.

• 	În fereastra de urmărire, faceți clic pe marginea de lângă o linie de cod. Aceasta setează un punct de întrerupere „pauză la locație” și afișează un punct roșu în margine pentru a indica punctul de întrerupere. Faceți dublu clic pe aceeași linie din nou, pentru a șterge punctul de întrerupere.

• 	În fereastra ceasului, faceți clic pe marginea de lângă orice expresie urmărită. Aceasta setează un punct de întrerupere „când expresia se schimbă” și afișează un punct roșu în margine pentru a indica punctul de întrerupere.

• 	Din meniul instrumentelor de depanare, alegeți „Puncte de întrerupere” pentru a afișa un dialog în care puteți seta în mod explicit oricare dintre diferitele tipuri de puncte de întrerupere. Cu toate acestea, din câte știm, acesta este și singurul loc în care puteți seta opțiunea PASS COUNT pentru un punct de întrerupere „la locație”. Acesta este un util

unul de reținut dacă doriți să setați un punct de întrerupere în interiorul unei bucle, dar să nu îl executați până când nu au avut loc un anumit număr de iterații ale buclei.

• Adăugați un „SET STEP On” explicit oriunde în orice cod. Acest lucru va suspenda necondiționat execuția și va afișa depanatorul cu fereastra de urmărire deschisă.

Când rulați depanatorul în propriul cadru, un dialog suplimentar arată toate punctele de întrerupere definite în prezent și vă permite să le activați/dezactivați selectiv. Rețineți că butonul „Șterge Α1Γ nu numai că dezactivează toate punctele de întrerupere, ci le șterge și din istoric.

Figura 13.1 Dialogul BreakPoint

În ciuda fișierului de ajutor care afirmă că „ctkl+b” va afișa acest dialog fie în cadrul Debug, fie în cadrul FoxPro, acest dialog nu pare să fie disponibil atunci când rulează depanatorul în FoxPro Frame.
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Expresii utile punct de întrerupere

Adesea, cea mai dificilă decizie este cum să faceți ca Visual FoxPro să se spargă exact în punctul dorit, fără a fi nevoie să adăugați cod explicit la orice testați. Iată câteva sugestii pe care le-am găsit utile:

Utilizați un punct de întrerupere „bazat pe timp”.

Destul de des dorim să examinăm starea obiectelor noastre imediat după o anumită interacțiune a utilizatorului - ca imediat după o casetă de mesaj sau un alt dialog modal. Introduceți o expresie de ceas ca aceasta:

MINUT(DATETIME())

și setați un punct de întrerupere pe el. Apoi rulați codul de testare și așteptați la dialogul corespunzător până când minutul se schimbă înainte de a ieși din dialog. Punctul de întrerupere va opri imediat execuția și vă va permite să examinați starea sistemului. Aceeași expresie poate fi folosită și pentru a opri bucle mari (sau nesfârșite!).

Utilizați funcția programului

Pentru a seta un punct de întrerupere care se va declanșa ori de câte ori este executat un program sau o metodă specificat, utilizați o expresie ca:

„metoda de verificare” $ LOWER( PROGRAM() )

Aceasta va trece de la .F. la .T. ori de câte ori „checkmethod” începe să se execute și setând un punct de întrerupere „când se schimbă expresia”, puteți opri execuția chiar la începutul blocului de cod. Acest lucru poate și ar trebui să fie foarte specific - mai ales atunci când doriți să întrerupeți un apel către o metodă VFP nativă care poate exista în multe obiecte. De exemplu, următorul punct de întrerupere se va întrerupe numai atunci când metoda Click a unui obiect numit „cmdnexf începe să se execute:

„cmdnext.click” $ LOWER( PROGRAM() )

în timp ce următoarea linie va intra atunci când se execută orice metodă a aceluiași obiect 'cmdnexf:

„cmdnext” $ LOWER( PROGRAM() )

Limitarea punctelor de întrerupere la modificări

Una dintre problemele legate de utilizarea unui punct de întrerupere „când se modifică expresia” este că Visual FoxPro va considera expresia urmărită ca fiind modificată atunci când ceea ce este monitorizat intră sau iese din domeniul de aplicare. Pentru a evita acest lucru și a limita pauzele la acele ocazii în care valoarea sa schimbat cu adevărat, utilizați o funcție iif() pentru a returna o constantă din expresia ceasului, cu excepția cazului în care valoarea sa schimbat cu adevărat. De exemplu, următoarea expresie va întrerupe execuția programului ori de câte ori o variabilă numită InCnf este în domeniu și se schimbă la sau de la o valoare de „3”, dar în caz contrar va fi total ignorată:

IIF(TYPE("lnCnt")="N" ȘI lncnt = 3, .T., .F.)

În mod similar, valoarea returnată de la un test setcdatasession") poate fi utilizată pentru a se asigura că, atunci când se depanează cu mai multe sesiuni de date deschise, numai cea corectă este urmărită de către depanator. Astfel, se stabilește un punct de întrerupere pe o expresie de urmărire ca aceasta:

IIF( SET("DATASESSION") # 1, ALIAS(), "WRONG DS")

se va întrerupe numai atunci când aliaso-ul selectat curent se schimbă într-o sesiune de date, cu excepția sesiunii de date implicite Visual FoxPro (adică DataSession = 1).

Cum mă asigur că metodele mele personalizate se declanșează atunci când mă aștept?

Una dintre cele mai mari probleme pe care le întâlnim cu toții atunci când lucrăm cu obiecte este că nu este întotdeauna evident când se declanșează evenimente. Scopul Event Tracker, care este încorporat în depanator, este să vă permită să urmăriți secvența în care se declanșează evenimentele native ale Visual FoxPro. Prin activarea Urmăririi evenimentelor, puteți direcționa Visual FoxPro să ecou numele evenimentelor și metodelor pe măsură ce se declanșează, fie în fereastra de ieșire de depanare, fie într-un fișier text. Cu toate acestea, nu puteți urmări toate evenimentele și metodele native ale Visual FoxPro și nu există nicio prevedere pentru urmărirea metodelor personalizate. Deci, dacă trebuie să urmăriți exact ceea ce se execută, trebuie fie să utilizați înregistrarea de acoperire, fie să includeți cod pentru a crea un fișier jurnal în clasele dvs.

Din fericire, introducerea funcției STRTOFILE() în Versiunea 6.0 face acest lucru într-adevăr foarte simplu. O singură linie de cod este tot ceea ce este necesar, după cum urmează:

STRTOFILE(program + CHR(1O) + CHR(13), „<nume fișier jurnal>”, .t. )

Aceasta va scoate numele metodei sau procedurii care se execută în prezent în fișierul specificat. Parametrul final asigură că textul este adăugat la fișierul țintă dacă acesta există deja, altfel STRTOFILE() ar suprascrie pur și simplu fișierul jurnal.

Am folosit această tehnică pentru a monitoriza exact ce cod dintr-o aplicație compilată este de fapt executat în timpul „testării utilizatorului”. Pentru a face acest lucru selectiv, împachetăm linia de cod care scrie fișierul jurnal într-un test pentru o variabilă de sistem (citit din fișierul INI al aplicației la pornire). După aceea, simpla schimbare a setărilor din fișierul INI ne permite să activăm și să dezactivăm înregistrarea timpului de rulare.
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Scrierea codului pentru ușurință de depanare și întreținere

Au existat multe pagini de sfaturi bune scrise pentru a încerca să-i convingă pe programator că ar trebui să adopte bune practici defensive, să folosească convenții de denumire adecvate și standardizate și să-și planifice codul înainte de a-l scrie. Din păcate, prea des încă vedem lucruri care ne fac să ne întrebăm dacă unii programatori sunt chiar de la distanță deranjați să-și testeze, să depaneze și chiar să își mențină codul. Iată câteva dintre gândurile noastre, pentru cât valorează, despre scrierea unui cod mai bun.

Utilizați o convenție de denumire a variabilelor/proprietăților

Au existat multe dezbateri în comunitatea FoxPro de-a lungul anilor despre subiecte precum dacă „m”. prefixul este un lucru bun de utilizat sau dacă convenția standard Microsoft ar trebui adoptată pentru denumirea variabilelor în toate situațiile. Nu credem că contează prea mult care sunt de fapt detaliile convenției tale de denumire, atâta timp cât ești consecvent în aplicarea acesteia. De ce asa?

Motivul este că Visual FoxPro este un limbaj slab tastat. Cu alte cuvinte, nu impune tastarea datelor pentru proprietățile sau variabilele sale. Aceasta înseamnă că, fără testare specifică, nu puteți fi sigur ce tip de date deține de fapt o variabilă, deoarece o variabilă își derivă tipul din datele sale și se modifică pentru a reflecta orice date i se oferă. Acesta este, în mod paradoxal, atât unul dintre punctele forte ale Visual FoxPro, cât și unul dintre marile sale slăbiciuni.

Este un punct forte pentru că ne permite să definim o variabilă oriunde avem nevoie de una (fără a fi nevoie să o declarăm în mod formal) prin simpla atribuire a unei valori unei referințe. Acest lucru face ca limbajul de programare să fie foarte flexibil și ușor de utilizat.

Este o slăbiciune din două motive. În primul rând, înseamnă că nu trebuie să existe un singur loc într-o metodă, procedură sau funcție în care să fie declarate toate variabilele utilizate. Acest lucru poate duce la re-declararea aceluiași nume de variabilă în locuri diferite din cod. O altă consecință este că erorile tipografice minore cauzează erori în timpul rulării, deoarece ceea ce este de fapt un nume de variabilă scris greșit este acceptat de compilator ca o nouă declarație de variabilă. În al doilea rând, înseamnă că chiar și atunci când o variabilă a fost declarată explicit, denumită și inițializată cu un anumit tip de date, simplul act de atribuire a datelor de un tip nepotrivit nu va genera o eroare. Variabila se modifică pur și simplu pentru a se adapta datelor.

Pentru a rezolva prima problemă, vă recomandăm insistent să vă faceți un obicei de a declara orice variabile pe care le creați într-o anumită parte a programului (în mod normal chiar de la început). Nu există o modalitate ușoară de a evita a doua problemă, cu excepția asigurării că atunci când datele sunt atribuite unei variabile, numele acelei variabile indică corect tipul de date. Acest lucru poate duce la crearea și utilizarea mai multor variabile, dar, în opinia noastră, acesta este un preț mic de plătit pentru claritate și ușurință de întreținere.

În timp ce utilizarea unei convenții de denumire nu va preveni de fapt erorile, descoperim că tinde să faciliteze menținerea lucrurilor separate din punct de vedere conceptual și astfel minimizează șansa de a introduce erori. Dacă vă extindeți convenția de denumire pentru a include obiecte, câmpuri și fișiere, depinde într-adevăr de dvs., dar aceste lucruri sunt în general mai puțin semnificative imediat. Considerăm că este mai bine să ne asigurăm că există o documentație adecvată pentru o bază de date și tabelele acesteia, precum și pentru proprietățile și metodele expuse ale claselor.

Păstrați procedurile și metodele cât mai scurte posibil

Acest lucru poate suna evidente, dar mai puțin cod înseamnă mai puține erori. Mai important, este mai ușor să gestionați codul și să înțelegeți logica atunci când aveți de-a face cu metode sau proceduri clar concentrate. Ca regulă generală, o metodă ar trebui să se ocupe de una, și doar una, piesa specifică de funcționalitate. (Adoptarea acestui principiu face, de asemenea, mai ușoară denumirea metodelor!) Cu cât este mai mare gradul în care o metodă este supraîncărcată, cu atât este mai dificil de menținut și cu atât este mai mare riscul ca ceva să meargă greșit.

Utilizați instrucțiuni „return” în codul de metodă și de procedură

La fel ca majoritatea programatorilor Visual FoxPro, avem tendința de a fi puțin neglijenți în utilizarea instrucțiunilor Return, mai ales atunci când nu returnăm de fapt o valoare în mod explicit. De cele mai multe ori aceasta nu este o problemă. Compilatorul FoxPro este suficient de inteligent pentru a accepta că atunci când rămâne fără cod într-un singur loc, ar trebui să se întoarcă la fragmentul de cod care l-a pornit și va implementa o întoarcere „implicită” pentru noi. Totuși, acest lucru poate cauza probleme la depanarea codului, mai ales în situațiile în care ultima linie care trebuie executată este fie un apel de funcție, fie un apel la o altă metodă. Adăugând instrucțiunea de returnare explicită, aveți ocazia să vă opriți în metoda de apelare atunci când urmăriți codul în depanator.

Utilizați aserțiuni pentru a ajuta la identificarea erorilor în timpul dezvoltării

Afirmațiile sunt extrem de valoroase pentru dezvoltator, deoarece ne permit să gestionăm problemele diferit în timpul dezvoltării și în timpul execuției, fără a fi nevoie să schimbăm vreun cod. Acest lucru se datorează faptului că Visual FoxPro va executa o linie de cod care începe cu o instrucțiune „assert” numai dacă codul rulează în modul de dezvoltare și set asserts este activat. În orice altă situație, linia este tratată ca și cum ar fi un comentariu și nu interferează cu execuția programului.

O utilizare comună a assert este de a avertiza dezvoltatorii (și testerii) atunci când ceva nu s-a comportat așa cum era de așteptat. Obiectivul aici este de a oferi informații suplimentare atunci când se testează în dezvoltare. Următorul fragment de cod arată cum se poate face acest lucru:

luSomeVar = SomeProcessResult()

IF VARTYPE( luSomeVar ) # "C"

AFIRMĂ .F. MESAJ „SomeProcessResult a căzut pentru a returna un șir de caractere”

RETURNARE .F.

ENDIF

Mesajul de eroare va fi afișat numai când set asserts este activat și procesul nu reușește să returneze un șir de caractere. În toate celelalte situații, dacă procesul nu reușește să returneze un șir de caractere, codul va returna pur și simplu un .F logic. și să-și continue executarea normală.

A doua utilizare comună a Asserts este verificarea logicii de programare. Acest lucru este ușor diferit de primul exemplu prin aceea că testul, în acest caz, va fi efectuat numai atunci când aserțiunile sunt activate și astfel la

timpul de rulare testul nici nu va fi încercat:

ASSERT PCOUNT() # 3 MESAJ „Se așteptau 3 parametri, primiți” + PADL(PCOUNT(),2)

Păstrați procesarea și logica separate

Una dintre cele mai ușoare modalități de simplificare a codului este să vă asigurați că nu amestecați procesarea și logica. Ca exemplu a ceea ce ne referim, luați în considerare următorul cod care a fost preluat, așa cum se arată aici, dintr-o aplicație reală:

IF cheknam(alltrim(table2.legal_name ))== cheknam(alltrim(;

thisform.pageframel.pagel.textl.value)) ȘI NU cheknam(alltrim(;

table2 .legal_name) ) == cheknam(alltrim(curval ( ' legal_name ' , ' CUMPĂRĂTOR ' ) )

Acest lucru poate părea foarte grozav - dar cum naiba ar trebui să interpreteze și să depaneze așa ceva? De fapt, dacă verificați cu atenție această linie de cod, veți descoperi că de fapt lipsește o paranteză! Cum ar fi trebuit scrise declarațiile? Ei bine, poate ceva de genul acesta ar fi fost puțin mai clar:

*** Efectuați mai întâi toate funcțiile ChekNam().

lcSceName = ChekNam( ALLTRIM( table2.legal_name ))

lcInpName = ChekNam( ALLTRIM( ThisForm.PageFramel.Pagel.Textl.value ))

lcLegName = ChekNam( ALLTRIM( CURVAL( 'nume_legal', 'CUMPĂRĂTOR')))

*** Acum fă testul!

DACĂ lcSceName == lcInpName ȘI NU lcSceName == lcLegName

De ce credem noi că este mai bine? Există trei motive:

• 	Apelurile la funcția ChekNam() sunt tratate separat. Prin urmare, putem verifica, (în depanator chiar dacă nu am vrut să plasăm cod de verificare în program) că valorile returnate sunt într-adevăr ceea ce ne așteptăm.

• 	Putem reduce efectiv numărul de apeluri pe care le facem către funcția ChekNam. Testul necesită ca valoarea pe care am numit-o lcSceName să fie folosită de două ori, astfel încât codul original trebuie să facă două apeluri la funcție, trecând aceeași valoare de fiecare dată.

• 	Acum am separat logica programului de procesarea efectuată de funcția ChekNam(). Aceasta înseamnă că, chiar și fără să știm ce face funcția ChekNam(), putem vedea cel puțin ce testează de fapt instrucțiunea IF și putem valida rezultatele în depanator.
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Lucrul cu sesiuni de date

Nu am acoperit utilizarea sesiunilor de date în mod specific în nicio altă parte a cărții - în principal pentru că nu am putut decide dacă subiectul era legat de date sau de formulare. Iată câteva sfaturi și trucuri pentru utilizarea sesiunilor de date.

Cum partajez sesiunile de date între formulare?

De fapt, este foarte ușor să obțineți un formular (sau un raport) pentru a utiliza sesiunea de date privată a obiectului care l-a numit. Pur și simplu setați proprietatea DataSession a obiectului copil la „1 - Sesiune de date implicită”. Acest lucru funcționează din cauza modului în care Visual FoxPro interpretează termenul „Implicit” în acest context și nu este ceea ce v-ați putea aștepta în mod rezonabil!

Când porniți pentru prima dată Visual FoxPro și deschideți „Fereastra sesiune de date”, veți observa că sesiunea de date curentă este „Implicit(l)”. Setarea proprietății sesiunii de date a unui formular la „1 - Sesiune DefaultData” ar părea probabil să se asigure că formularul utilizează aceeași sesiune de date numărul 1 la care VFP se referă ca Implicit. Din păcate, acest lucru nu este neapărat adevărat! În acest context, termenul „Implicit” într-adevăr înseamnă că formularul NU creează o sesiune de date privată pentru sine, ci doar folosește orice sesiune de date este actuală atunci când este instanțiată. Acesta este motivul pentru care un formular a cărui proprietate de sesiune de date este lăsată la „1 -Sesiune de date implicită” partajează sesiunea de date a formularului care îl lansează.

Dacă un formular folosește propriul mediu de date pentru a tabelelor AutoOpen/AutoClose, numai acele tabele care sunt deschise efectiv de formularul copil vor fi închise. Cu alte cuvinte, dacă formularul copil necesită un tabel care este deja deschis în sesiunea de date a formularului părinte, Visual FoxPro este suficient de inteligent pentru a recunoaște acest fapt și nu va redeschide astfel de tabele atunci când formularul copil este instanțiat sau nu le va închide atunci când forma de copil este eliberată.

Un lucru de remarcat este că, dacă permiteți unui formular să partajeze în sesiunea de date privată a altuia, atunci când eliberați formularul copil, numele sesiunii de date curente Visual FoxPro se va schimba în „Necunoscut(n)”, unde „n” este numărul sesiunii de date. din formularul care a creat inițial sesiunea de date. Cu toate acestea, acest lucru nu pare să cauzeze nicio problemă în Visual FoxPro, deși poate fi puțin deranjant când observați prima dată că se întâmplă. Motivul pare să fie că, deși Visual FoxPro este capabil să redenumească sesiunea de date la proprietarul actual atunci când formularul copil este instanțiat, nu știe cum să o redenumească atunci când acel formular este lansat și așadar pur și simplu îl lasă ca „ Necunoscut'.

Cum schimb sesiunile de date?

În ciuda informațiilor contrare din fișierul de ajutor, proprietatea DataSessionID a unui formular este de fapt citire-scriere în timpul rulării. Prin urmare, puteți forța un formular să ruleze într-o anumită sesiune de date setând proprietatea DataSessionID direct în cod. Cu toate acestea, dacă aveți controale legate pe formular, modificarea sesiunii de date a formularului după ce acestea au fost legate vă va cauza probleme serioase. Gradul de severitate va depinde de controlul în cauză. O grilă își va pierde pur și simplu RecordSource și va rămâne goală irevocabil. O casetă listă a cărei sursă de rând este preluată dintr-un tabel va provoca o eroare „Nu se poate accesa tabelul selectat” și va dispărea, în timp ce o casetă combinată va rămâne goală. Interesant, reconectarea formularului la sesiunea de date corectă va restabili lucrurile la normal atât în cazul casetelor listă, cât și al casetelor combinate, deși nu și pentru grile. Morala acestei povești este că dacă ai nevoie

modificați sesiunea de date a unui formular, faceți-o în LOAD-ul formularului înainte ca orice controale să fi fost instanțiată și nu permiteți mediului de date al formularului să tabele AutoOpen.

Totuși, pot exista ocazii în care va trebui să manipulați proprietatea DataSessionID a unui obiect. De exemplu, barele de instrumente sunt adesea necesare pentru a se comuta în sesiunea de date a formularului activ în prezent. (Clasa noastră de bare de instrumente „gestionată” din Capitolul 10 are un astfel de cod și aceasta nu este o problemă, deoarece astfel de bare de instrumente generice nu au controale legate de date.)

Pentru obiectele care nu au o proprietate DataSessionID, trebuie să utilizați comanda SET DATASESSION pentru a modifica sesiunea globală de date. Acest lucru poate fi necesar pentru un obiect global (de exemplu, un obiect de aplicație) care este creat în sesiunea de date implicită Visual FoxPro, dar care poate avea nevoie de acces la tabelele deschise printr-un formular într-o sesiune de date privată. Cu condiția să salvați mai întâi sesiunea de date curentă și să o restaurați imediat după aceea, acest lucru nu ar trebui să cauzeze probleme, chiar și atunci când sunt prezente alte obiecte cu controale legate de date. Următorul fragment de cod arată cum:

*** Salvați DS curent

InDSID = SET(„DATASESSION”)

*** Schimbați sesiunea de date

SETATE DATASESSION LA <număr nou de sesiune>

*** Faceți tot ce este necesar și apoi reveniți

SETĂ SESIUNEA DE DATE LA (InDSID)

Cum obțin o listă cu toate sesiunile de date active? (Exemplu: getallds.prg)

Nu există o modalitate nativă de a obține o listă a tuturor sesiunilor de date active în mod programatic, dar deoarece în mod normal ne-ar interesa doar sesiunile de date utilizate de formulare, putem folosi colecția Screen.Forms pentru a determina care sunt active. Următoarea funcție face exact acest lucru și populează o matrice (care este transmisă prin referință) cu numărul sesiunii de date și numele obiectului proprietar. Funcția returnează numărul de sesiuni de date active pe care le găsește:

**************************************************** ********************

* 	Program. GetAllDS.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Populați matricea cu toate sesiunile de date deschise

* 	..........:Treceți matricea țintă prin referire la această funcție

* 	..........:DIMENSION ADSList[1]

* 	..........:lnNumSess = GetAllDs( @aDSList )

**************************************************** ********************

LPARAMETRI taSesiuni

Sesiuni EXTERNAL ARRAY

LOCAL lnCurDatasession, lnSessions

*** Inițializați contorul

lnsesiuni

0

*** Buclă prin colecția de formulare

PENTRU FIECARE oForm ÎN _ECRAN.FORME

*** Avem deja această sesiune?

IF ASCAN( tasSessions, oForm.DatasessionID) = 0

*** Dacă nu, adăugați-l în matrice

InSessions = InSessions + 1

DIMENSION tasSessions[InSessions,2] tasSessions[lnSessions,1] = oForm.DatasesionID tasSessions[lnSessions,2] = oForm.Name

ENDIF

URMĂTORUL

*** Returnați numărul de sesiuni

RETORN lnSessions
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Articole diverse

Restul acestui capitol este o colecție de lucruri pe care nu le-am inclus în mod specific în altă parte. Nu există nicio legătură anume între ele, dar merită menționate, chiar dacă doar ca reamintire.
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Care este secvența de evenimente când o formă este instanțiată sau distrusă?

Așa cum se întâmplă adesea cu Visual FoxPro, răspunsul este că „depinde”. În acest caz, depinde dacă formularul este instanțiat dintr-un fișier SCX folosind „do form” sau dintr-un fișier VCX folosind createobject() sau hewobject() . Instanțiarea formei ca clasă este cea mai simplă, iar aici este succesiunea evenimentelor:

FORM.LOAD

INIT pentru fiecare control

FORM.INIT

FORMĂ. SPECTACOL

FORM.ACTIVARE

FORM.REFRESH

Sf

CÂND pentru 1 secunde '■*

control în Taborder

Sf

GOTFOCUS pentru 1 secunde '■*

Control în Taborder

(daca are unul)

Secvența de bază de pornire este, așadar, dată de acronimul „LISAR”. În mod implicit, controalele individuale de pe formular sunt instanțiate în ordinea în care au fost adăugate la clasă din designer. Cu toate acestea, folosind opțiunile „Aduceți în față și „Trimiteți în spate”, puteți modifica secvența în care sunt instanțiate controalele. (Deși chiar nu ar trebui să conteze în ce ordine sunt instanțiate lucrurile. Crearea de clase care se bazează pe instanțiarea controalelor într-o anumită ordine nu este, în opinia noastră, un design bun!)

Eliberarea unei clase de formular este în esență inversul procesului de inițializare. Metoda Release oferă mijloacele de inițiere programatică a procesului, în timp ce metoda QueryUnload este apelată atunci când un utilizator face clic pe butonul „închidere fereastră” dintr-un formular. Niciunul nu îl apelează pe celălalt decât dacă adăugați cod în mod specific pentru a-i face să facă acest lucru, dar ambii apelează metoda Destroy a formularului:

FORM.RELEASE sau FORM.QUERYUNLOAD

FORM.DISTRUGE

DISTRUGE pentru fiecare control (în ordine inversă)

FORM.DESCARCARE

Aceasta înseamnă că, dacă doriți ca codul să fie executat, indiferent dacă utilizatorul închide un formular făcând clic pe un buton de comandă (care apelează Release) sau butonul „Închidere fereastră” (care apelează QueryUnload), atunci acel cod trebuie să fie plasat în metoda Destroy a formei.

În cazul unui formular creat dintr-un SCX, secvența de bază a evenimentelor de formular este aceeași, dar prezența DataEnvironmentului nativ complică problema. Observați că metoda Dataenvironment OpenTables este prima metodă numită (se declanșează BeforeOpenTables) - chiar înainte ca metoda Load a formularului să fie apelată. După ce metoda de încărcare a formularului s-a finalizat cu succes, cursoarele sunt inițializate. Acest lucru asigură că atunci când controalele formularului sunt instanțiate, cele care sunt legate de date vor putea face acest lucru corect:

DATE MEDIU.PENTABLES

DATE MEDIU.ÎNAINTE DE DESCHIS

FORM.LOAD

INIT pentru fiecare cursor din DataEnvironment

MEDIUL DE DATE . INIT

INIT pentru fiecare control din formular

FORM.INIT

FORM.ARAȚI

FORM.ACTIVARE

FORM.REFRESH

Sf

CÂND pentru 1^ control în Taborder

Sf

GOTFOCUS pentru 1s 	Control în Taborder (dacă are unul)

Procesul de eliberare este, în ceea ce privește forma în sine, identic cu cel de mai sus. Observați că DataEnvironment nu este de fapt distrus decât după ce formularul a fost descărcat din memorie:

FORM.RELEASE sau FORM.QUERYUNLOAD

FORM.DISTRUGE

DISTRUGE pentru fiecare control (în ordine inversă)

FORM.DESCARCARE

MEDIU DE DATE .DUPĂ ÎNCHIDERE

DATEENVIRONMENT.DISTRUGERE

DISTRUGE pentru fiecare Cursor din DE (în ordine inversă)
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Cum obțin o referință la formularul părinte al unui formular?

Există câteva moduri de a face acest lucru, cea mai evidentă fiind pur și simplu ca forma părinte să treacă o referință la sine atunci când apelează formularul copil - astfel:

DO FORM <forma copil> CU This

Cu toate acestea, aceasta necesită ca metoda Init a formularului copil să fie configurată pentru a primi referința la obiect ca parametru și apoi să o stocheze într-o proprietate de formular. Interesant, obiectul indicat de proprietatea __Screen.ActiveForm a lui Visual FoxPro nu se schimbă atunci când un formular nou este instanțiat până când metoda Init a acelui formular nu se finalizează cu succes. (Acest lucru are sens când vă amintiți că returnarea unui .f logic fie din metodele Load sau Init va împiedica instanțiarea noului formular.)

Prin urmare, pentru a obține o referință la formularul de apelare, nu este nevoie să treceți deloc. Pur și simplu stocați __Screen.ActiveForm într-o proprietate în metoda Load sau Init a formularului copil. În mod normal, am plasa acest tip de cod în metoda Load (pentru a lăsa Init liber pentru manipularea parametrilor) astfel:

IF TYPE ("_Screen.ActiveForm.Name") # "U"

ThisForm.oCalledBy = _Screen.ActiveForm

ENDIF

Rețineți că nu putem folosi în mod fiabil funcția vartypeo aici, deoarece va eșua dacă nu există nicio formă activă.
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Cum obțin o listă cu toate obiectele dintr-un formular?

Obiectul Formular Visual FoxPro are o colecție numită „Controls” și o proprietate asociată contorului („ControlCount”) conține o referință la fiecare obiect din formular. Cu toate acestea, această colecție conține doar referințe la obiecte care sunt conținute DIRECT de formular. Deci, de exemplu, nu va include obiecte care se află pe o pagină, în interiorul unui cadru de pagină din formular. Tot ce va avea este referința la cadru de pagină. Pentru a obține o listă a tuturor obiectelor, va trebui, prin urmare, să „detailăm” în fiecare container întâlnit.

Din fericire, fiecare clasă de container Visual FoxPro are o colecție (și contor asociat) care conține referințe la obiectele pe care le deține containerul. Din păcate, aceste colecții nu sunt toate numite la fel, așa cum indică următorul tabel:

Tabelul 13.3 Colecții de clasă container

	Proprietatea de bază ClassCollectionCounter
	_ScreenFormsFormCount
	_ScreenControlsControlCount
	FormsetFormsFormCount
	FormControlsControlCount
	ToolbarControlsControlCount
	PageFramePagesPageCount
	PageControlsControlCount
			

Grid 	ColumnsColumnCount
Column 	ControlsControlCount
Container 	ControlsControlCount
Controale personalizateControlCount	
Control 	ControlsControlCount

Această variație a denumirii face scrierea unei rutine care va detalia un formular puțin mai dificilă, deoarece trebuie să testăm clasa de bază a fiecărui container pe care îl întâlnim pentru a stabili cum se numește proprietatea de colectare a acestuia. Exemplul de formular LogCtrls.Scx are o metodă personalizată recursivă (GetControls) și o proprietate personalizată de matrice (aAllControls) care este utilizată ca colecție pentru toate controalele și este populată de metoda personalizată AddToCollection. În cele din urmă, o metodă personalizată RegisterControls este utilizată pentru a inițializa proprietatea matricei și pentru a începe procesul de detaliere prin apelarea metodei GetControls cu o referință la formularul însuși. Iată codul pentru metoda RegisterControls:

*** LogCtrls::Metoda RegisterControls

*** Inițializează colecția de formulare și apelează GetControls() recursiv

CU ThisForm

*** Ștergeți lista curentă (dacă există)

DIMENSIUNE .aAllControls[1,3]

.aAllControls = ""

*** Începeți explorarea cu obiectul formular în sine

.GetControls( Aceasta )

SE TERMINA CU

Metoda GetControls este puțin mai complexă. Primul lucru pe care îl face este să creeze o referință locală la obiectul care i-a fost transmis ca parametru (rețineți că va folosi formularul în sine dacă nu se transmite nimic). Apoi apelează metoda AddToCollection pentru a adăuga obiectul la colecție și apoi stochează clasa de bază a obiectului într-o altă variabilă locală pentru a fi utilizată mai târziu:

*** LogCtrls::Metoda GetControls

*** Detaliază formularul și populează matricea de colecții personalizată

LPARAMETERS toStartObj

LOCAL loRef, lnCnt, lnControls, loObj

*** Obține referință la părinte sau la formular, în mod implicit

loRef = IIF( TYPE('toStartObj')='O', toStartObj, THISFORM )

*** Adăugați acest obiect la colecție

ThisForm.AddToCollection( loRef )

*** Obțineți clasa de bază a obiectului curent

lcClass = LOWER(ALLTRIM(loRef.BaseClass))

În continuare, trebuie să stabilim cu ce fel de obiect avem de-a face în iterația curentă. Mai întâi verificăm dacă avem de-a face cu una dintre clasele care utilizează altceva decât o colecție de „controale”. Dacă da, apelăm recursiv metoda GetControls în timp ce parcurgem colecția obiectului respectiv:

*** Acum Procesați obiectul curent

FACE CAZ

CASE lcClass = „cadru de pagină”

FOR lnCnt = 1 TO loRef.PageCount

*** Apelați această metodă pentru fiecare pagină

THISFORM.GetControls( loRef.Pages[lnCnt] )

URMĂTORUL

CAZ lcClass = „grilă”

FOR lnCnt = 1 TO loRef.ColumnCount

*** Apelați această metodă pentru fiecare coloană

THISFORM.GetControls( loRef.Columns[lnCnt] )

URMĂTORUL

CAZ lcClass = 'formset'

FOR lnCnt = 1 TO loRef.FormCount

*** Apelați această metodă pentru fiecare formular

THISFORM.GetControls(loRef.Forms[lnCnt] )

URMĂTORUL

Orice altă clasă de container va folosi o colecție „Controls”, astfel încât să le putem procesa pe toate într-o singură declarație case. (Rețineți că verificăm, folosind o comparație exactă, pentru clasa de bază „pagină”. Acest lucru este pentru a evita căderea în comparație cu șiruri de caractere ușor idiosincratică a Visual FoxPro, care ar returna .t. dacă am include pur și simplu „pagina” în listă, dar obiectul era un „cadru de pagină”.)

Dacă obiectul curent este un container, acest cod trece prin colecția de controale. Din nou verificăm clasa de bază a fiecărui obiect pe care îl întâlnim și, dacă este un alt container, apelăm metoda GetControls pasând recursiv o referință la obiect. Cu toate acestea, dacă nu este un container, o referință la acesta este transmisă metodei AddToCollection, astfel încât să poată fi înregistrată:

*** OK, este un obiect care are o colecție de controale?

CASE INLIST(lcClass, 'formular', 'container', 'coloană', 'personalizat', 'control') );

SAU lcClass = „pagină”

*** Dacă da, parcurgeți colecția sa

FOR lnCnt = 1 TO loRef.ControlCount

*** Obțineți o referință la obiectul curent

loObj = loRef.Controls[lnCnt]

IF INLIST(loObj.BaseClass, 'Container', 'Pageframe', 'Grid', 'Custom', 'Control' )

*** Apelați această metodă recursiv dacă este un container conținut

ThisForm.GetControls( loObj )

ALTE

*** Doar adăugați obiectul în colecție

ThisForm.AddToCollection(loObj)

ENDIF

URMĂTORUL

Dacă obiectul curent nu declanșează niciuna dintre condițiile din această instrucțiune case, nu este un container și a fost deja înregistrat, astfel încât să îl putem ignora în siguranță și să ieșim din acest nivel de recursivitate:

IN CAZ CONTRAR

*** Nimic de făcut la acest nivel

ENDCA.SE

*** Doar întoarce-te

ÎNTOARCERE

Singurul alt cod este cel care adaugă de fapt un obiect la colecția „aAllControls” a formularului. Acest lucru este într-adevăr foarte simplu, deoarece primește o referință directă la obiectul pe care trebuie să îl înregistreze ca parametru din metoda GetControls:

LPARAMETRI toObj

LOCAL loRef

IF VARTYPE(toObj ) # "O"

*** Dacă nu este un obiect, întoarce-te

ÎNTOARCERE

ALTE

*** Obțineți referință locală

loRef = toObj

ENDIF

După ce ați verificat dacă parametrul este într-adevăr un obiect, următoarea sarcină este să determinați câte articole au fost deja înregistrate:

CU ThisForm

*** Obțineți numărul de rânduri deja în colecție

lnControls = ALEN( .aAllControls, 1 )

*** Dacă 1 rând - este populat?

DACA lnControls = 1

lnControls = IIF( EMPTY( .aAllControls[1,1]), 0, 1 )

ENDIF

*** Creșteți contorul

lnControls = lnControls + 1

Un nou rând este apoi adăugat la colecție și elementele colecției sunt populate:

*** Adăugați un rând la matrice

DIMENSIUNEA .aAllControls[ lnControls, 3]

*** Populați noul rând

.aAllControls[ lnControls, 1] = loRef.Name && Nume obiect

.aAllControls[ lnControls, 2] = loRef && Referință obiect

.aAllControls[ lnControls, 3] = SYS(1272, loRef ) && Ierarhia obiectelor

SE TERMINA CU

*** Întoarce-te

ÎNTOARCERE

Există multe situații în care este util să poți parcurge toate controalele dintr-un formular. În timp ce acest cod este scris în mod special pentru a popula o matrice de colecție, cu excepția celor două apeluri la metoda AddToCollection, codul este complet generic și poate fi folosit oricând este necesar să detaliezi un formular. În plus, deoarece metoda GetControls este apelată cu o referință la obiect, nu trebuie să înceapă cu formularul. Poate începe doar cu orice referință la obiect pe care i se transmite.
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Cum pot seta focalizarea pe primul control din ordinea file?

Un răspuns la această întrebare este că ați putea folosi un cod similar cu cel dat în secțiunea precedentă pentru a detalia un container (adică formularul sau o pagină dintr-un formular) pentru a găsi obiectul conținut care are proprietatea TabIndex setată la 1. Apoi, pur și simplu setați focalizarea pe acel obiect și ieșiți.

Alternativ, atunci când utilizați formulare cu mai multe pagini, în loc să executați în mod repetat acest cod de detaliere, ați putea prefera să construiți o colecție specială (când formularul este instanțiat) pentru a înregistra pentru fiecare pagină o referință la obiectul care se află primul în Ordinea tabulatorilor. Apoi, tot ce ar fi nevoie ar fi să scanezi acea colecție pentru pagina necesară și să se concentreze pe obiectul specificat.
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Cum returnez o valoare dintr-o formă modală?

În altă parte, am discutat deja câteva tehnici de trecere a parametrilor între obiecte de diferite tipuri. Ceea ce nu am acoperit în mod specific nicăieri altundeva sunt diferitele tehnici de recuperare a valorilor dintr-o formă modală. Conceptul de „returnarea unei valori” are sens doar atunci când formularul care returnează valoarea este modal, deoarece cerința implicită este ca un proces să fie întrerupt sau suspendat până când valoarea necesară este returnată. Numai prin utilizarea unui formular modal vă puteți asigura că:

• 	Procesul nu poate continua până când valoarea nu este disponibilă

• 	Valoarea este returnată la locul corect din codul de apelare.

Există în esență trei moduri de a obține o valoare înapoi dintr-un formular modal, dar una dintre ele funcționează numai pentru formularele care sunt rulate ca fișiere SCX, una lucrează cu formulare care sunt instanțiate din fișiere VCX și una funcționează indiferent de modul în care este creat formularul. . Amintiți-vă că, deși vorbim despre returnarea „o valoare”, această „valoare” ar putea fi un obiect parametru care conține mai multe elemente (consultați Capitolul 2 „Funcții și proceduri” pentru mai multe informații despre crearea și utilizarea obiectelor parametri).

Returnarea unei valori dintr-un formular

Mecanismul real pentru returnarea unei valori dintr-un formular este destul de simplu. Pur și simplu plasați o comandă RETURN <valoare> ca ultima linie de cod în metoda UNLOAD a formularului. Aceasta este ultima metodă de formular care trebuie executată înainte ca un formular să fie lansat și, prin urmare, este un loc perfect logic pentru instrucțiunea return. Cu toate acestea, există o mică captură. Dacă valoarea pe care doriți să o returnați provine dintr-un control din formular, în momentul în care metoda de descărcare a formularului rulează toate controalele au fost eliberate, astfel încât valorile pe care le dețin nu vor mai fi disponibile. Pentru a ocoli această problemă, trebuie să vă asigurați că toate valorile de control pe care doriți să le returnați sunt salvate în proprietățile formularului cel târziu în metoda Distrugerea formularului. (Consultați secțiunea de mai devreme în acest capitol pentru detalii despre secvența evenimentelor când un formular este instanțiat sau distrus.)

Ascunderea unei forme modale

O modalitate de a obține acces la valorile care sunt conținute într-o formă modală este pur și simplu să ascundeți formularul în loc să îl eliberați. Când o formă modală este ascunsă, oricare dintre forme a fost activă imediat înainte de instanțierea formei modale devine din nou forma activă. Cu alte cuvinte, forma care a numit forma modală este reactivată. Cu condiția să aveți, în cadrul formularului de apelare, o referință validă la formularul modal, puteți accesa orice proprietăți expuse ale formularului sau ale controalelor sale. Această abordare va funcționa indiferent de modul în care este instanțiată formularul.

Următorul fragment de cod arată cum se poate face acest lucru pentru un formular instanțiat direct dintr-o clasă:

*** Instanțiați o formă modală

oFm = NEWOBJECT( 'modalform' , 'formclasses' )

*** Afișați formularul și asigurați-vă că este modal

oFm. Arată (1)

*** Când formularul este „eliberat”, este de fapt ascuns!

*** Accesați direct proprietățile formularului Modal

ThisForm.SomeProperty = oFm.ModalFormProperty

*** Eliberați forma modală când ați terminat

oFm.Release ()

În timp ce pentru un formular care este creat dintr-un fișier SCX, următorul cod este echivalent:

*** Instanțiați forma modală

DO FORM modalform NAME ofm LINKED

*** Când forma modală este „eliberată” este de fapt ascunsă!

*** NUMELE „oFm” poate fi folosit acum pentru a-l accesa direct:

ThisForm.SomeProperty = oFm.ModalFormProperty

*** Eliberați formularul modal când ați terminat, eliberând „numele legat”

LANSAREA luiFm

Folosind do form <nume> la <variabilă>

Pentru formularele modale care au fost create ca fișiere SCX și care sunt rulate folosind comanda do form, există o sintaxă specifică pe care o utilizați pentru a salva o valoare care este returnată din formular, după cum urmează:

DO FORM modalform TO luRetVal

Când formularul modal este eliberat, orice a fost returnat din metoda Unload a formularului va fi salvat în variabila „luRetVal”. Rețineți că această variabilă nu trebuie să fi fost declarată anterior și va fi creată după cum este necesar. Totuși, dacă formularul apelat nu conține o instrucțiune return în metoda sa Unload, variabila nu va fi creată. Deci, în opinia noastră, este mult mai sigur să declarați întotdeauna în mod explicit variabila returnată și să o inițializați, mai degrabă decât să ne bazați pe existența unei instrucțiuni return.

Returnarea unei valori dintr-un formular instanțiat direct dintr-o clasă

Problema în această situație este că nu există nicio modalitate de a returna atât referința la obiect ȘI o valoare returnată fie din funcțiile Createobject, fie Newobject. Deoarece ambele trebuie să returneze o referință la noul obiect, trebuie să găsim o altă modalitate de a obține o valoare înapoi. Soluția este să treceți un obiect parametru în formular care poate fi apoi returnat de formularul modal atunci când este eliberat.

Clasa formular trebuie configurată pentru a primi și stoca într-o proprietate obiectul parametru care îi este transmis. (În mod normal, ar fi, de asemenea, ca metoda clasei Init să-și apeleze direct metoda Show pentru a face forma vizibilă imediat la instanțiere.). Acest obiect trebuie să fie populat cu proprietățile relevante în timp ce formularul este activ și returnat la metoda de apelare (sau procedura) din metoda Unload a formularului modal. Codul pentru a instanția forma modală ar arăta astfel:

*** Creați obiectul Parameter

oParamObj = CREATEOBJECT('parameterobject')

*** Instanțiați forma modală

oModalForm = CREATEOBJECT( 'modalformclass', oParamObj )

*** Verificați proprietățile obiectului returnat

IF oParamObj.FornWasOK

*** Fă orice

ALTE

*** Fă altceva

ENDIF
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Cum schimb indicatorul mouse-ului într-un formular în timp ce un proces rulează?

Ca de obicei, răspunsul de bază este foarte simplu. Toate controalele vizuale au proprietatea aMousePointer care determină forma cursorului mouse-ului atunci când cursorul este poziționat peste un control. Cu toate acestea, deoarece fiecare control are propria sa setare pentru controlul indicatorului mouse-ului, nu există o singură proprietate sau metodă pentru a controla proprietatea MousePointer pentru toate controalele dintr-un formular simultan.

Modul standard de a schimba toate valorile unei proprietăți pentru toate obiectele dintr-un formular este să folosești metoda SETALL a formularului. Următorul cod setează indicatorul mouse-ului pentru toate controalele dintr-un formular la „clepsidra”:

CU ThisForm

*** Setați cursorul mouse-ului propriu al formularului

.MousePointer = 11

*** Acum toate obiectele conținute

.SetAll( 'MousePointer', 11 )

SE TERMINA CU

Pentru a reveni la setarea implicită, repetați pur și simplu acest cod cu o valoare de 0 în loc de 11. Cu toate acestea, aceasta se bazează pe toate controalele din formular folosind aceeași setare de proprietate MousePointer în orice moment. Dacă aveți deja setări diferite ale proprietăților MousePointer pentru diferite clase de control, singura alternativă este să treceți în buclă prin toate controalele dintr-un formular și să salvați proprietatea MousePointer curentă a fiecărui control și să o setați în mod explicit la valoarea necesară. (Puteți folosi cod similar cu cel afișat în secțiunea „Cum obțin o listă a tuturor obiectelor dintr-un formular?” din acest capitol.). Pentru a restabili indicatorul mouse-ului, trebuie pur și simplu să repetați procesul și să citiți valoarea salvată. Considerăm că acesta este un scenariu destul de neobișnuit și, în mod normal, ne-am aștepta să găsim toate controalele folosind setarea lor „implicit” (MousePointer = 0).

Până acum, bine! Din păcate, există o excepție de la tot ce am spus mai sus atunci când este implicată o rețea. În timp ce o grilă are o proprietate MousePointer, nu suntem siguri de ce. În versiunea 6.0, oricum, nu pare să se comporte la fel ca alte controale și afectează afișarea doar atunci când mouse-ul se află peste o zonă a grilei care nu conține date. Indiferent la ce este setată proprietatea MousePointer a grilei, deplasarea mouse-ului peste porțiunea populată a grilei afișează întotdeauna cursorul fasciculului „I”.

Cea mai bună soluție cu care putem veni este să adăugați un obiect SHAPE transparent pentru a acoperi grila (cu excepția barelor de defilare). Rezultatul este că, de fapt, acesta este MousePointer-ul obiectului de formă pe care utilizatorul îl vede când își mută cursorul mouse-ului peste grilă. Desigur, dacă grila nu este Read-Only, trebuie să oferim un mecanism pentru detectarea unui clic pe formă și transferarea acestuia în porțiunea relevantă a grilei. Din fericire, câteva funcții noi din versiunea 6.0 ne pot ajuta aici. Exemplul de cod include un formular ("ChgMPtr.scx'") care arată cum funcționează. Iată codul din metoda Click al formei care suprapune grila:

*** Trebuie să știm numele grilei

CU ThisForm.grdVatrates

*** Folosiți AMOUSEOBJ() pentru a obține detalii despre poziția mouse-ului

LOCAL ARRAY laList[1]

AMOUSEOBJ( ultimaList, 1 )

*** Coordonatele X și Y sunt în rândurile 3 și 4

InX = laList[3]

InY = laList[4]

*** Inițializați unele variabile

InGObj = 0

lnGrow = 0

lnGCol = 0

*** Folosiți GRIDHITTEST() pentru a obține Grid Row/Col sub mouse

llStat = .GridHitTest(lnX, lnY, @lnGobj, @lnGRow, @lnGCol)

*** Trimiteți forma în spatele grilei

Aceasta.ZORDER(1)

*** Activați celula corectă din grilă

.ActivateCell( lnGRow, lnGCol)

.Seteaza focusul()

SE TERMINA CU

Acest cod determină locul în care a apărut clicul în formă și traduce acea poziție în rândul și coloana corespunzătoare a grilei. Apoi aruncăm forma în spatele grilei și activăm celula corectă. Singurul truc este că trebuie să restabilim forma în poziția ei „De sus” atunci când grila își pierde focalizarea, dar Grid nu are metoda LostFocus! Deci, trebuie să adăugăm cod la metoda Valid a grilei și să apelăm propria metodă ZOrder a grilei pentru a trimite grila „To Bottom”, restabilind astfel obiectul de formă la poziția sa inițială peste grilă.
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Cum pot crea o proprietate „globală” pentru aplicația mea?

În Visual FoxPro, proprietățile sunt limitate la obiecte, așa că nu este cu adevărat posibil ca o proprietate să fie „globală” în același mod în care o poate face o variabilă de memorie. Cel mai bun lucru pe care îl putem face este să definim proprietatea ca aparținând unui obiect al cărui domeniu de aplicare este global. Având în vedere această abordare, avem câteva opțiuni.

Mai întâi am putea pur și simplu să creăm un obiect din clasa necesară și să asociem referința acestuia cu o variabilă publică, astfel:

LANSA goGlobalObj ect

PUBLIC goGlobalObject

goGlobalObject = NEWOBJECT( <clasă>, <classlibrary> )

Orice din aplicație are acum acces la „goGlobalObject” și, prin urmare, la toate proprietățile și metodele sale. Acesta este modul în care un „Obiect de aplicație” (uneori cunoscut sub numele de „obiect zeu) este de obicei creat. Desigur, dacă obiectul este creat în programul de pornire al aplicației, nu este nevoie să declarați în mod explicit referința ca „Public”, cu condiția ca acesta să nu fie declarat în mod explicit ca „Local”. Orice variabilă privată creată în programul de pornire este oricum „publică” aplicației.

Odată cu introducerea în limbaj (în versiunea 6.0) a metodei AddProperty, a fost deschisă o alternativă intrigantă la crearea unui obiect global. Obiectul Visual FoxPro „Ecran” este de fapt un obiect global gata făcut și, deoarece are o metodă proprie AddProperty, putem pur și simplu să adăugăm orice proprietăți de care avem nevoie la nivel global direct la obiectul ecran, după cum urmează:

_Screen.AddProperty( 'CurrentUser', '' )

Dar stai, te auzim plângând, ce s-a întâmplat dacă rulezi aplicația cu ecranul oprit? De fapt, nu are nicio diferență. Obiectul Screen este în continuare disponibil chiar dacă nu îl afișați și puteți accesa în continuare proprietățile și metodele sale - inclusiv orice proprietăți personalizate sau cele ale obiectelor adăugate - în orice moment.
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Cum pot „răsfoi” o matrice? (Exemplu ArToCurs.prg)

Unul dintre iritante minore ale Visual FoxPro este că nu există o modalitate bună de a vedea de fapt conținutul unei matrice. Există, desigur, mai multe moduri de a ajunge la o matrice. Puteți folosi depanatorul pentru a extinde și a explora o matrice sau îl puteți lista pe ecran sau într-un fișier text, dar niciunul dintre ele nu este complet satisfăcător. La urma urmei, putem crea o matrice dintr-un cursor folosind SQL prin simpla lansare a unei comenzi ca aceasta:

SELECTAȚI <câmpuri> DIN <tabel> ÎN MATRIZĂ <nume>

Ceea ce nu putem face este opusul - transformați o matrice înapoi într-un cursor, astfel încât să o putem răsfoi sau să o vedem într-o formă sau orice altceva avem nevoie la momentul respectiv. Funcția ArToCurs face treaba pentru noi, luând o referință la o matrice și opțional un nume de cursor și construind un cursor din conținutul matricei.

Există o avertizare pentru codul prezentat aici. Această funcție nu va gestiona matrice care conțin referințe la obiecte. Nu ar fi dificil să modifici codul astfel încât să facă (poate prin obținerea numelui obiectului), dar această funcție nu a fost concepută în acest scop, așa că nu este scrisă așa. Valoarea returnată este numărul de rânduri din cursor care a fost creat. Iată codul:

**************************************************** ********************

* 	Program.ArToCurs.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Acceptă o matrice și o convertește într-un cursor

**************************************************** ********************

LPARAMETERS taSceArray, tcCursorName

LOCAL ARRAY laStru[1]

LOCAL LnRows, lnCols, lnCnt, lcColNum, lnColSize, lcInstr

MATRICE EXTERNĂ taSceArray

*** Verificați dacă avem o matrice ca parametru

*** NB Nu se poate folosi VarType() aici în cazul în care matricea NU există!

IF TYPE( "taSceArray[1]" ) = "U"

AFIRMĂ .F. MESAJ „Trebuie să treacă un Array valid către ArToCurs()”

ÎNTOARCERE

ENDIF

*** Numele implicit al cursorului la „arraycur” dacă nu a trecut nimic

lcCursor = IIF( VARTYPE( tcCursorName ) = "C" AND ! EMPTY( tcCursorName ), ;

ALLTRIM( LOWER( tcCursorName )), "arraycur" )

*** Determinați dimensiunea matricei

lnRows = ALEN(taSceArray,1)

lnCols = MAX( ALEN(taSceArray,2), 1 )

DIMENSIUNE laStru(lnCols, 4)

*** Creați matricea structurii

lcInstr = ""

FOR lnCnt = 1 TO lnCols

*** Coloane de nume cu tipul de date + numărul total zero

lcColNum = PADL( lnCnt, 5, „0” )

laStru[ lnCnt, 1 ] = VARTYPE( taSceArray[ 1, lnCnt] ) + lcColNum

laStru[ lnCnt, 2 ] = „C” && Tip de date

*** Determinați lățimea maximă necesară a coloanei

lnColSize = 1

FOR lnRowCnt = 1 TO lnRows

lnColSize = MAX( lnColSize, LEN( TRANSFORM( taSceArray[lnRowCnt, lnCnt] ))) NEXT

laStru[ lnCnt, 3 ] = lnColSize && Col Width

laStru[ lnCnt, 4 ] = 0 && Fără zecimale

*** Adăugați câmpul la Insert String

DACĂ ! GOL (lcInstr)

lcInStr = lcInstr + ","

ENDIF

DACA lnCols > 1

lcInStr = lcInstr+"TRANSFORM(taSceArray[lnCnt,"+ALLTRIM(STR(lnCnt))+"])" ELSE

lcInStr = lcInstr+"TRANSFORM(taSceArray[lnCnt"+"])"

ENDIF

URMĂTORUL

*** Creați cursorul din matricea structurii

CREATE CURSOR (lcCursor) FROM ARRAY laStru

*** Populați cursorul

FOR lnCnt = 1 TO lnRows

INSERT INTO (lcCursor) VALUES ( &lcInStr )

URMĂTORUL

GO TOP IN (lcCursor)

*** Returnează numărul de înregistrări

RETURN RECCOUNT( lcCursor )
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Windows API Calis

Există o mulțime de acestea și, din păcate, nu sunt bine documentate pentru utilizatorii Visual FoxPro. Iată câteva funcții Visual FoxPro care folosesc apeluri API pe care le-am găsit utile. Deși sunt prezentate aici ca funcții de sine stătătoare, în mod normal am colecta acest tip de funcții fie într-un fișier de procedură, fie ca metode ale unei clase. Avantajul utilizării unei clase vizuale (de exemplu, o clasă „personalizată”) este că atunci când aceste funcții sunt necesare, un obiect bazat pe clasă poate fi pur și simplu adăugat direct în formularul care are nevoie de el.

Una dintre cele mai mari probleme pentru majoritatea dezvoltatorilor Visual FoxPro atunci când încep să lucreze cu API-ul Windows este că funcțiile se bazează în mare măsură pe constante definite. Dar nu este întotdeauna ușor să determinați de unde provin de fapt aceste constante sau chiar ce sunt. Gary DeWitt a adunat și a pus foarte generos la dispoziția tuturor peste 4000 de constante Windows sub formă de declarații Visual FoxPro „#defihe”. O copie a fișierului său („windows.h”) este inclusă cu exemplul de cod pentru acest capitol.
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Cum găsesc fișierul asociat unui tip de fișier? (Exemplu: findexec.prg)

Această mică funcție este utilă deoarece vă spune unde se află fișierul executabil asociat cu o anumită extensie de fișier. Pentru orice extensie de fișier care are o asociere specifică Windows, valoarea returnată constă din calea completă și numele fișierului către programul executabil. Acest lucru poate fi apoi manipulat folosind funcțiile native Visual FoxPro ( JUSTPATH(), JUSTFNAME() etc) pentru a extrage orice informație de care aveți nevoie cu adevărat.

Rețineți că funcția API pe care o folosim aici (FindExecutable()) poate accepta o anumită cale și un nume de fișier, dar fișierul trebuie să existe. Deci, pentru a fi absolut siguri, am optat să creăm un fișier temporar, cu extensia necesară, în directorul de lucru curent și să folosim acel fișier pentru a determina rezultatul. Cu toate acestea, aceasta înseamnă că trecerea oricăreia dintre extensiile executabile Windows (adică „com”, „bat” sau „exe”), care nu sunt asociate unor aplicații specifice, va returna pur și simplu locația acestui fișier temporar. Aceasta nu este o problemă, deoarece întregul scop al funcției este de a determina unde se află programul executabil care rulează un tip de fișier neexecutabil:

**************************************************** ********************

* 	Program. FindExec.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Abstract...: Returnează calea completă și numele fișierului Windows exe

* 	..........:care este asociat cu funcția specificată

**************************************************** ********************

LPARAMETRI tcExt

LOCAL lcRetVal, lcFileExt, lcFileName, lnFileHandle, lcDirectory, lcResBuff

STORE „” ÎN lcRetVal, lcFileExt, lcFileName, lcDirectory

*** Verificați dacă a fost trecută o extensie

DACĂ VARTYPE(tcExt) # „C” SAU EMPTY(tcExt)

EROARE „9000: trebuie să treacă o extensie de fișier către FindExec()”

RETURN lcRetVal

ALTE

lcFileExt = UPPER( ALLTRIM( tcExt ))

ENDIF

*** Această funcție TREBUIE să aibă un fișier de tipul necesar

*** Așa că creați unul chiar aici (doar temporar)!

lcFileName = „DUMMY”. + lcFileExt

lnFileHandle = FCREATE(lcFileName)

DACA lnFileHandle < 1

*** Nu se poate crea fișierul

EROARE „9000: Nu se poate crea fișierul. FindExec() trebuie să se oprească”;

+ CHR(13) + „Verificați dacă aveți drepturile necesare pentru crearea fișierului”

RETURN lcRetVal

ENDIF

FCLOSE (InFileHandle)

*** Creați bufferul valorii returnate și declarați funcția API lcResBuff = SPACE(128)

DECLARE INTEGER FindExecutable ÎN SHELL32 ;

STRING @cFileName, ;

STRING @cDirectory, ;

STRING @cBuffer

*** Acum apelați-l cu numele fișierului și directorul

lnRetVal = FindExecutable( @lcFileName, @lcDirectory, @lcResBuff)

*** Verificați valoarea returnată

lcMsgTxt = ""

FACE CAZ

CAZ lnRetVal = 0

lcMsgTxt = „Memorie sau resurse lipsite”

CAZ lnRetVal = 2

lcMsgTxt = „Fișierul specificat nu a fost găsit”

CAZ lnRetVal = 3

lcMsgTxt = „Calea specificată nu a fost găsită”

CAZ lnRetVal = 11

lcMsgTxt = „Format EXE nevalid”

CAZ lnRetVal = 31

lcMsgTxt = „Fără asociere pentru tipul de fișier” + lcFileExt

IN CAZ CONTRAR

*** Am primit ceva înapoi

*** Șirul este terminat cu nul în buffer-ul rezultat, astfel:

lcRetVal = LEFT(lcResBuff, AT(CHR(0), lcResBuff) - 1)

ENDCASE

*** Ștergeți fișierul fals pe care l-am creat.

ȘTERGE FIȘIER (lcFileName)

*** Afișați rezultatele și reveniți

DACĂ ! GOL (lcMsgTxt)

MESSAGEBOX(lcMsgTxt, 16, „FindExec a eșuat”)

ENDIF

RETURN lcRetVal
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Cum pot deschide un fișier folosind asocierile de fișiere Windows? (Exemplu: runfile.prg)

Acest lucru este remarcabil de simplu folosind funcția ShellExecute(). Această funcție fie deschide, fie tipărește fișierul specificat (care poate fi fie un fișier executabil, fie un document). Iată codul:

**************************************************** ********************

* 	Program.RunFile.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Deschideți sau imprimați un fișier/document numit folosind asocierea Windows

**************************************************** ********************

LPARAMETERS tcDocName, tlPrint

LOCAL lnRetVal, lnShow, lcAction

*** Verificați parametrii

IF VARTYPE (tcDocName) # „C” SAU EMPTY(tcDocName)

AȘTEPTĂȚI FEREASTRĂ „Trebuie să transmiteți un nume și o extensie de document valide” ACUM Așteptați

ÎNTOARCERE

ENDIF

*** Trebuie să aibă și o extensie

IF EMPTY( JUSTEXT(tcDocName ))

AȘTEPTĂȚI FEREASTRĂ „Trebuie să transmiteți un nume și o extensie de document valide” ACUM Așteptați

ÎNTOARCERE

ENDIF

*** Verificați acțiunea, dacă tlPrint = .T., „Print” în caz contrar „Open”

lcAction = IIF( tlPrint, „Print”, „Open” )

lnShow = IIF( tlPrint, 0, 5 )

*** Declarați funcția API

DECLARE INTEGER ShellExecute IN Shell32.dll;

LONG HWnd, ;

STRING cAcțiune, ;

STRING cFileName, ;

STRING cParametri, ;

STRING cPath, ;

INTEGER nShowWindow

*** Acum executați-l

lnRetVal = ShellExecute( 0, lcAction, tcDocName, "", "", lnShow)

ÎNTOARCERE

Rețineți că am setat această funcție pentru a accepta o cale complet calificată și un nume de fișier ca un singur parametru. De fapt, l-ați putea folosi la fel de bine, împărțind parametrul în nume de fișier și cale și trecându-le separat ca parametrii cFileName și cPath.

Valoarea nShowWindow este setată la 5 (adică „Afișați” aplicația) când deschideți un document și la 0 (ascundeți aplicația) când imprimați un document. (Gama completă de valori poate fi găsită în fișierul WinUser.h sub titlul „Comenzi ShowWindow()”.)
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Cum pot obține numele de conectare Windows al utilizatorului? (Exemplu:

getlogin.prg)

Există de fapt o modalitate pur VFP de a obține aceste informații prin utilizarea funcției SYS(0) care returnează numele mașinii și numele de conectare curent al utilizatorului. Valoarea returnată este un singur șir și folosește simbolul pentru a separa numele mașinii de numele utilizatorului. Deci o soluție posibilă este utilizarea:

IcCurrentUser = ALLTRIM( SUBSTR( SYS(0), AT('#', SYS(0))+1))

Cu toate acestea, există și o funcție GetUserName() care va returna aceleași informații și care poate fi încapsulată ca o funcție simplă, definită de utilizator, după cum urmează:

**************************************************** **

* 	Program.GetLogIn.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Obțineți numele de conectare Windows

**************************************************** **

LOCAL lcUserName, lcRetVal

*** Declarați funcția API

DECLARE GetUserName IN Win32Api;

STRING @cString, ;

INTEGER @nBuffer

*** Inițializați tampoanele

lcUserName = SPACE(50)

*** Obțineți numele de conectare

GetUserName( @lcUserName, LEN(lcUserName) )

*** Șirul este terminat cu nul în buffer-ul rezultat, astfel:

lcRetVal = LEFT(lcUserName, AT(CHR(0), lcUserName) - 1)

*** Returnați ID-ul de conectare

RETURN lcRetVal
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Cum pot obține informații despre director? (Exemplu: windir.prg)

API-ul Windows conține mai multe funcții care pot fi folosite pentru a obține informații despre director. Unele sunt disponibile și din Visual FoxPro (de exemplu, schimbarea directorului curent), în timp ce altele nu sunt (de exemplu, găsirea directoarelor Windows sau System). Următorul program colectează mai multe dintre aceste funcții împreună și utilizează un index numeric pentru a determina acțiunea necesară, după cum urmează:

Tabelul 13.4 Funcțiile directorului API

Acțiune index	
1 	Returnează calea completă către directorul de sistem Windows.
2 	Returnează calea completă către directorul principal Windows.
3 	Returnează calea completă către directorul de lucru curent. (Echivalent cu „CD” în Visual FoxPro).
4 	Acceptă un parametru suplimentar care este fie o cale relativă, fie o cale complet calificată și face ca directorul de lucru curent. Returnează fie directorul curent complet calificat, fie un mesaj de eroare dacă directorul specificat nu există.
5 	Acceptă un parametru suplimentar care este fie o cale relativă, fie o cale complet calificată și creează directorul. Returnează fie „Creat”, fie „Eșuat”.
6 	Acceptă un parametru suplimentar care este fie o cale relativă, fie o cale complet calificată și șterge directorul. Returnează fie „Eliminat”, fie „Eșuat”.

Este demn de remarcat faptul că aceste funcții vor gestiona fie identificatorii de unitate UNC, fie convenționali cu o facilitate egală, ceea ce le poate face utile în unele situații. Iată codul:

**************************************************** ********************

* 	Program.WinDir.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Funcții Windows API Directory

* 	..........:Opțiuni de apelare

* 	..........:1->ReturnWindowsSystem Directory

* 	..........:2->ReturnWindowsDirectory

* 	..........:3->ReturnCurrentWorking Directory

* 		:4,<cale> -> Setați directorul de lucru (Acceptă calea relativă)
* 		:5,<cale> -> Creați director numit (Acceptă calea relativă)
* 		:6,<cale> -> Eliminați directorul numit (Acceptă calea relativă)

**************************************************** ********************

LPARAMETERS tnWhich, tcDirName

LOCAL lcSysDir, lnBuffer, lnDirLen, lcRetVal

*** Inițializați tampoanele

lcSysDir = REPLICATE(CHR(0),255)

lnBuffer = 255

*** Efectuați apelul corespunzător

Faceți CASE

CAZ tnWhich = 1

*** Director de sistem Windows

DECLARE INTEGER GetSystemDirectory ÎN Win32API;

STRING @cBuffer, ;

INTEGER nDimensiune

*** Apelați funcția

lnDirLen = GetSystemDirectory( @lcSysDir, lnBuffer )

lcRetVal = LEFT( lcSysDir, lnDirLen )

CAZ tnWhich = 2

*** Director de sistem Windows

DECLARE INTEGER GetWindowsDirectory ÎN Win32API;

STRING @cBuffer, ;

INTEGER nDimensiune

*** Apelați funcția

lnDirLen = GetWindowsDirectory( @lcSysDir, lnBuffer )

lcRetVal = LEFT( lcSysDir, lnDirLen )

CAZ tnWhich = 3

*** Director de lucru curent

DECLARE INTEGER GetCurrentDirectory ÎN Win32API;

INTEGER nSize, ;

STRING @cBuffer

*** Apelați funcția

lnDirLen = GetCurrentDirectory( lnBuffer, @lcSysDir )

lcRetVal = LEFT( lcSysDir, lnDirLen )

CAZ tnWhich = 4

*** Setați directorul implicit

DECLARE INTEGER SetCurrentDirectory ÎN WIN32API;

STRING cNewDir

*** Apelați funcția, returnați numele dacă este OK, șir gol dacă nu lcRetVal = IIF( SetCurrentDirectory( tcDirName) = 1, tcDirName, ; "Directorul nu există")

CAZ tnWhich = 5

*** Creați director

DECLARE INTEGER CreateDirectory ÎN WIN32API;

STRING cNewDir, ;

STRING cAttrib

*** Apelați funcția

lnSuccess = CreateDirectory ( tcDirName, "")

lcRetVal = IIF( lnSuccess = 1, „Creat”, „Failed” )

CAZ tnWhich = 6

*** Eliminați directorul

DECLARE INTEGER RemoveDirectory ÎN WIN32API;

STRING cKillDir

*** Apelați funcția

lnSuccess = RemoveDirectory (tcDirName)

lcRetVal = IIF( lnSuccess = 1, „Eliminat”, „Eșuat” )

IN CAZ CONTRAR

*** Parametru necunoscut

lcRetVal = ""

ENDCASE

*** Returnează locația directorului

RETURN lcRetVal

Rețineți că opțiunea „elimină directorul” va funcționa numai dacă directorul țintă este gol de toate fișierele.
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Cum pot obține numărul de culori disponibile? (Example: wincois.prg)

Numărul de culori poate fi calculat din numărul de biți de culoare care sunt alocați pentru fiecare pixel. Aceasta este una (din multe) valori care pot fi obținute folosind funcția GetDeviceCaps(). Cu toate acestea, pentru a determina de unde să-și obțină valorile, acestei funcții trebuie să i se transmită id-ul de context (care este obținut din funcția GetDC()) pentru a obține care avem nevoie de mânerul Windows „WHnd”. Acest lucru poate fi obținut fie utilizând biblioteca FoxTools astfel:

SETĂ BIBLIOTECA LA ADITIVUL FoxTools.fll

lnHWND = _WHTOHWND( _WMainWind() )

sau, ca și aici, funcția API GetActiveWindow() poate fi utilizată pentru a returna mânerul în fereastra principală FoxPro:

**************************************************** ********************

* 	Program. ...: WinCols.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Abstract...: returnează numărul de culori disponibile

**************************************************** ********************

LOCAL lnHWND, lnBitsPixel, lnDeviceContext

*** Declarați funcțiile API

DECLARAȚI INTEGER GetActiveWindow ÎN WIN32API

DECLARE INTEGER GetDC IN Win32Api;

INTEGER nWHnd

DECLARE INTEGER GetDeviceCaps IN Win32Api;

INTEGER nDeviceContext, ;

INTEGER nValueToGet

*** Obțineți mânerul Windows pentru fereastra activă

lnHWND = GetActiveWindow()

*** Obțineți mai întâi contextul dispozitivului pentru fereastra curentă

lnDeviceContext = GetDC(lnHWND)

*** Apoi obțineți numărul de biți de culoare per pixel

lnBitsPixel = GetDeviceCaps( lnDeviceContext, 12)

*** Rezultatul returnat

RETURN (2 л lnBitsPixel)
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Cum obțin valorile pentru setările de culoare Windows? (Exemplu: getwcol.prg)

Există două părți implicate în acest proces. Mai întâi trebuie să recuperăm setarea de culoare pentru elementul Windows necesar din Windows însuși. (Există o funcție API care va face acest lucru.) Apoi convertim acea valoare în componentele roșii, verzi și albastre pe care le putem folosi în Visual FoxPro. (Deși, dacă tot ceea ce faceți este să setați o proprietate de culoare, atunci Visual FoxPro poate utiliza direct numărul de culoare Windows și conversia nu este necesară.) Iată funcția:

**************************************************** ********************

* 	Program. GetWCol.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: returnează valorile culorilor roșu, verde și albastru pentru a

* 	..........:dată culoarea obiectului Windows numerotată

**************************************************** ********************

LPARAMETERS tnObjectNumber

*** Verificați parametrul

IF VARTYPE( tnObjectNumber ) # "N" SAU ! BETWEEN( tnObjectNumber, 0, 28)

WAIT WINDOW „Trebuie să treacă numărul de culoare Windows între 0 și 28” ACUM Așteptați

ÎNTOARCERE

ENDIF

*** Obțineți setarea de culoare necesară

DECLARE INTEGER GetSysColor IN Win32API;

INTEGER nObiect

lnWinCol = GetSysColor(tnObjectNumber)

*** Convertiți în valori RGB

lnSq256 = 256 л 2

lnRedGrn = MOD( lnWinCol, lnSq256 )

*** Acum obțineți componentele individuale

lcBlue = TRANSFORM( INT( lnWinCol/lnSq256 ) )

lcGreen = TRANSFORM( INT( lnRedGrn/256) )

lcRed = TRANSFORM( MOD( lnRedGrn,256) )

*** Returnează șirul RGB

RETURN (lcRoșu + "," + lcVerde + "," + lcAlbastru)

Această funcție necesită o constantă numerică care identifică un element Windows. Toate acestea sunt definite în fișierul „Windows.h” inclus cu exemplul de cod pentru acest capitol, dar unele dintre cele cheie sunt enumerate aici pentru comoditate.

Tabelul 13.5 Constante pentru culorile elementelor Windows

Constant

Culoarea elementului Windows

1 	fundal (Windows Desktop)
2 	Bară de titlu (Fereastra activă)
3 	Bara de titlu (Fereastra inactivă)
5 	Fereastra de fundal
9 	Textul subtitrării barei de titlu (fereastra activă)
19 	Textul subtitrării barei de titlu (Fereastra inactivă)
13 	Elementul evidențiat de fundal
14 	Textul articolului evidențiat
17 	Butonul de comandă
18 	Textul butonului de comandă
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Cum schimb cursorul? (Exemplu: ChgCursor.prg)

Vă puteți personaliza cu ușurință cursoarele folosind API-ul Windows. De exemplu, puteți înlocui clepsidra statică standard cu o clepsidră animată care se rotește, doar lansând acest apel de funcție:

ChgCursor( FUIIPATH( 'HourGlas.ani' ), 32514 )

Rețineți că funcția ChgCursor() acceptă doi parametri. Primul este numele fișierului care urmează să fie folosit pentru cursor - în exemplul de mai sus acesta este unul dintre fișierele de cursor „animate” standard Windows. Al doilea parametru este o constantă care definește ce tip de cursor (adică I-beam, mână, clepsidră) va fi înlocuit cu noul fișier. Aceste constante pot fi găsite în Windows.h și o listă a acestora este inclusă și în ChgCursor.prg însuși.

O bună utilizare pentru această funcție este să schimbați cursorul standard I-beam cu o săgeată atunci când doriți să utilizați o grilă care este fie numai pentru citire, fie care arată ca o casetă listă, folosind o singură linie de cod (spre deosebire de metodologia pe care am prezentat-o mai devreme în acest capitol):

ChgCursor( FUIIPATH( 'Arrow_m.cur' ), 32513 )

Trebuie doar să țineți cont de faptul că, dacă o faceți, tot cursorul dvs. I-beam va fi înlocuit de săgeată. Aceasta include orice casete de text care pot fi pe formular, așa că asigurați-vă că modificarea se aplică numai atunci când mouse-ul este peste grilă. Iată programul pe care îl folosim pentru a schimba cursorul:

**************************************************** ********************

* 	Program....: ChgCursor.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Abstract...: Schimbă cursorul specificat în fișierul .cur sau .ani specificat

**************************************************** ********************

IPARAMETERS tcCursorFile, tnCursorType

IOCAI lcNewCursor

ASSERT VARTYPE( tcCursorFile ) = 'C' ;

MESAJ „Trebuie să treci un nume de fișier la ChgCursor.Prg”

ASSERT VARTYPE( tnCursorType ) = 'N' ;

MESAJ „Trebuie să treacă un tip de cursor numeric la ChgCursor.Prg”

IF INIIST( JUSTEXT( tcCursorFile ), 'CUR', 'ANI' )

IF FIIE( tcCursorFile )

DECIARE INTEGER IoadCursorFromFile în Win32Api String

DECIARE SetSystemCursor în Win32Api Integer, Integer

lcNewCursor = IoadCursorFromFile( tcCursorFile )

SetSystemCursor( lcNewCursor, tnCursorType )

ENDIF

ENDIF
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Cum îmi personalizez bipurile? (Exemplu: MsgBeep.Prg)

Dacă vă uitați la sunetele de sistem din panoul de control Windows, veți observa că sunt definite sunete diferite pentru diferite tipuri de evenimente. Este o chestiune foarte simplă să utilizați aceste setări pentru a reda sunete care sunt în concordanță cu alte aplicații Windows atunci când afișați o casetă de mesaj în Visual FoxPro. Este și mai convenabil deoarece constantele pictogramei casetei de mesaje sunt identice cu cele utilizate pentru a identifica sunetele asociate în API-ul Windows. Pentru a reda sunetul asociat cu oprirea critică configurată în panoul de control Windows, tot ce trebuie să faceți este următorul:

MsgBeep( 16 )

Programul folosit pentru a încheia această funcție API este într-adevăr foarte simplu:

**************************************************** ********************

* 	Program.MsgBeep.prg

* 	Compilator...: Visual FoxPro 06.00.8492.00 pentru Windows

* 	Rezumat...: Redați sunetul specificat de sistem ca un bip

* 	Rețineți că constantele bip corespund constantelor pictogramei MESAGEBOX

**************************************************** ********************

LPARAMETRI tnBeep

DECLARE INTEGER MessageBeep ÎN INTEGER Win32API

MessageBeep (tnBeep)
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Cum aflu dacă rulează o anumită aplicație? (Exemplu:

IsRunning.prg)

Pe măsură ce citiți ajutorul Window API, puteți accesa funcția FindWindow și vă gândiți că o puteți utiliza pentru a afla dacă o anumită aplicație rulează. Din păcate, această funcție necesită să cunoașteți legenda exactă afișată în bara de titlu a ferestrei aplicației. Uneori acest lucru este imposibil. De exemplu, atunci când un document este editat în Microsoft Word, legenda ferestrei Word conține numele documentului care este editat. Deoarece în general nu este posibil ca aplicația dvs. Visual FoxPro să cunoască aceste detalii, nu putem folosi funcția FindWindow() pentru a determina dacă Word rulează. Pentru a rezolva această problemă, funcția noastră IsRunning() folosește funcția Windows API GetWi ndowT ex t.

IsRunning() este o funcție supraîncărcată. Dacă este apelat fără parametri, returnează un obiect parametru care conține o proprietate matrice. Această matrice conține numele tuturor aplicațiilor care rulează. Dacă este trecut un șir parțial, cum ar fi „Microsoft Word”, acesta returnează un adevărat logic dacă aplicația rulează. Dacă doriți să extindeți funcționalitatea acesteia, o puteți modifica pentru a returna o matrice bidimensională și a popula a doua coloană a matricei cu mânerul de fereastră al aplicației:

**************************************************** ********************

* 	Program.IsRunning.prg

* 	Compiler...:Visual FoxPro06.00.8492.00pentru Windows

* 	Rezumat...: Când este trecut astring (de exemplu, „Microsoft Word”), returnați .T.

* 	..........:dacă aplicația rulează. Când este invocat fără parametri,

* 	..........:returnează un obiect parametru a cărui matrice listează toate cele care rulează

* 	..........:aplicații

**************************************************** ************************

FUNCȚIA IsRunning

LPARAMETRI luAplicație

LOCAL luRetVal, lnFoxHwnd, lnWindow, lnWhich, lcText, ;

lnLen, laApps[1], lnAppCnt

*** Declarați funcțiile Windows API necesare

DECLARE INTEGER GetActiveWindow IN Win32Api

DECLARE INTEGER GetWindow IN Win32Api ;

INTEGER lnWindow, ;

INTEGER lnWhich

DECLARE INTEGER GetWindowText IN Win32Api;

INTEGER lnWindow, ;

STRING @lcText, ;

INTEGER lnLen

DECLARE INTEGER IsWindowVisible IN Win32Api;

INTEGER lnWindow

lnAppCnt = 0

*** Aduceți HWND (mânerul) în fereastra principală FoxPro lnFoxHwnd = GetActiveWindow()

DACĂ lnFoxHwnd = 0

MESSAGEBOX( „Valoare returnată nevalidă de la GetActiveWindow”, 16, „Eroare fatală” )

ÎNTOARCERE

ENDIF

*** Parcurge toate aplicațiile care rulează

lnWindow = GetWindow( lnFoxHwnd, 0 )

FACEȚI CÂND în fereastra # 0

*** Asigurați-vă că nu avem fereastra Visual Foxpro

IF lnWindow # lnFoxHwnd

DACĂ GetWindow( lnWindow, 4 ) = 0 AND IsWindowVisible( lnWindow ) # 0

lcText = SPAȚIU ( 254 )

lnLen = GetWindowText( lnWindow, @lcText, LEN( lcText ) )

*** Dacă funcției a primit un nume de aplicație, verificați dacă există o potrivire

*** În caz contrar, adăugați acest lucru în matrice

DACA lnLen > 0

IF VARTYPE( luApplication ) = 'L'

lnAppCnt = lnAppCnt + 1

DIMENSION laApps[ lnAppCnt ]

laApps[ lnAppCnt ] = LEFT( lcText, lnLen )

ALTE

IF UPPER( ALLTRIM( luApplication ) ) $ UPPER( ALLTRIM( lcText ) )

RETURNARE .T.

ENDIF

ENDIF

ENDIF

ENDIF

ENDIF

*** Vedeți dacă există o altă aplicație care rulează

lnWindow = GetWindow( lnWindow, 2 )

ENDDO

*** Fie nu am găsit o potrivire pentru numele aplicației transmise

*** sau returnăm o serie de aplicații care rulează

IF VARTYPE( luApplication ) = 'L'

SETARE CLASLIB LA ADITIVUL Ch13

luRetVal = CREATEOBJECT('xParameters', @laApps )

ALTE

luRetVal = .F.

ENDIF

RETURN luRetVal

Pentru a vedea IsRunning() în acțiune, trebuie doar să tastați do DemoIsRunning în fereastra de comandă (după ce ați descărcat și dezarhivat codul eșantion, desigur!) pentru a vedea un cursor care listează toate aplicațiile care rulează.
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Folosind comanda DECLARE

Veți fi realizat din secțiunile precedente că cheia pentru accesarea API-ului Windows este comanda Visual FoxPro declare. Această comandă înregistrează o funcție care este definită într-un Windows Dynamic LinkedLibrary {.DLL fișier) și o face disponibilă pentru Visual FoxPro ca și cum ar fi de fapt o funcție nativă. Vă puteți gândi la DLL-uri ca fiind echivalentul Windows al fișierelor de procedură familiare Visual FoxPro, dar, spre deosebire de un fișier de procedură, funcțiile conținute într-un DLL trebuie înregistrate individual înainte de a putea fi accesate.

Sintaxa de bază și utilizarea DECLARE sunt explicate destul de clar în fișierele de ajutor online și chiar mai clar în „Ghidul hackerilor pentru Visual FoxPro 6.0”, dar există câteva puncte care merită subliniate atunci când lucrați cu funcții API:

• 	Numele funcției este de fapt sensibil la majuscule! Acest lucru este cel mai neobișnuit în Visual FoxPro și, prin urmare, merită menționat aici. Dacă primiți o eroare care spune „Nu se poate găsi punctul de intrare....” atunci aproape sigur că ați greșit cazul pentru numele funcției.

• 	Nu numai că numele funcției ține seama de majuscule și minuscule, dar în unele cazuri este posibil ca numele funcției efective să nu fie același cu cel menționat. (Acest lucru se datorează faptului că pot exista funcții diferite pentru seturi de caractere diferite. Astfel, funcția API „Messagebox” este de fapt două funcții - „MessageBoxA” care funcționează cu seturi de caractere pe un singur octet și „MessageBoxW” pentru seturi de caractere unicode. În mod normal, nu trebuie să vă faceți griji pentru acest lucru, deoarece, dacă Visual FoxPro nu poate găsi funcția specificată, va adăuga un „A” și va încerca din nou.)

• 	Nu există un astfel de fișier ca „WIN32API.DLL” în ciuda faptului că veți vedea adesea funcții declarate în această bibliotecă. De fapt, este o „comandă rapidă” care instruiește Visual FoxPro să caute o listă predefinită de fișiere, inclusiv: Kernel32 .dll, Gdi32.dll, User32.dll, Mpr.dll și Advapi32.dll.

• 	Când declarați o funcție, puteți specifica un alias local pentru acea funcție incluzând cuvântul cheie „AS” în declarație. Acest lucru poate fi util deoarece, în timp ce numele funcției actuale este sensibil la majuscule și minuscule, aliasul local (fiind cunoscut doar de Visual FoxPro) nu este.

Cum verific ce funcții API sunt încărcate?

Raportul de stare a afișajului nativ include, la sfârșit, o listă a tuturor funcțiilor DLL declarate împreună cu fișierul real în care se află funcția, așa cum este ilustrat:

DLL-uri declarate:

GetActiveWindow C:\WINDOWS\SYSTEM\USER32.DLL

GetSystemDirectory C:\WINDOWS\SYSTEM\KERNEL32.DLL

GetWindow C:\WINDOWS\SYSTEM\USER32.DLL

GetWindowText C:\WINDOWS\SYSTEM\USER32.DLL

IsWindowVisible C:\WINDOWS\SYSTEM\USER32.DLL

Cum eliberez o funcție API?

Din păcate, nu există nicio modalitate de a elibera o singură funcție API odată ce aceasta a fost declarată. Emiterea fie a unui CLEAR DLLS, fie a unui CLEAR ALL va elibera toate funcțiile declarate, dar cel puțin în acest caz, este într-adevăr „totul sau nimic!”
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Capitolul 14 - Managementul proiectului

„După o privire asupra planetei, orice vizitator din spațiu ar spune „VREAU SĂ VĂD MANAGERUL”. " ("Mașina de adăugare" de William Burroughs)

Dezvoltatorii FoxPro au folosit Managerul de proiect pentru a gestiona fișierele de la introducerea FoxPro 2.0. Acest capitol va discuta câteva trucuri Manager de proiect în Visual FoxPro.

Managerul de proiect a fost un instrument important pentru dezvoltatorii Visual FoxPro de-a lungul anilor. Permite dezvoltatorilor să organizeze toate fișierele care sunt incluse pentru o aplicație. Oferă un mecanism ușor de a modifica oricare dintre aceste fișiere și de a compila tot codul sursă inclus în proiect, precum și de a construi fișiere APP, EXE și DLL. Lansarea Visual FoxPro 6.0 Service Pack 3 permite, de asemenea, dezvoltatorilor să construiască obiecte COM cu mai multe fire.

Managerul de proiect este interfața VFP cu fișierul de metadate ale proiectului. Fișierul de metadate ale proiectului este un tabel gratuit VFP care se termină cu extensia PJX și un fișier memo care are extensia PJT. Aceste fișiere combină informații despre fiecare fișier care este urmărit în proiect. Fișierele de metadate ale proiectului conțin o înregistrare per fișier și un indicator de referință la fiecare fișier. Informații precum numărul versiunii, numele autorului și adresa, dacă codul sursă este inclus în executabil din motive de depanare și dacă executabilul este criptat, sunt de asemenea urmărite în fișierul de proiect.
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Ce se întâmplă la construirea unui executabil?

Construirea unui proiect presupune mai mulți pași. În primul rând, toate fișierele la care se face referire în cod sunt verificate pentru a fi în proiect. Dacă nu sunt în proiect, procesul de compilare le caută în toate directoarele deja referite în proiect (prin fișiere deja din proiect) și le adaugă. Dacă nu sunt găsite, dezvoltatorului i se solicită să le localizeze manual. Fiecare fișier este compilat dacă sursa a fost actualizată de la ultima versiune, procedurile stocate ale bazelor de date sunt compilate și codul de meniu este generat și compilat. Restul procesului depinde de alegerea tipului de construcție selectat.

Există mai multe opțiuni de compilare disponibile în Visual FoxPro 6.0, Service Pack 3 (cea mai recentă actualizare de la Microsoft de la scrierea acestei cărți). Remarcăm versiunea VFP, deoarece Service Pack 3 a introdus cea mai nouă opțiune de construcție, DLL-ul server COM cu mai multe fire. Dialogul de compilare a fost modificat pentru a reflecta această nouă opțiune și pentru a clarifica exact pentru ce sunt folosite celelalte opțiuni de construcție.

Opțiunea de construire a proiectului de reconstrucție îi spune VFP să treacă prin procesul descris anterior. Nu mai este efectuată nicio acțiune. Aceasta este de departe cea mai rapidă dintre opțiunile de construire.

Opțiunea de construire a aplicației efectuează acțiunile care sunt efectuate pentru o reconstrucție și apoi îmbină toate fișierele sursă marcate pentru includere într-un fișier executabil în stil aplicație (.APP). Acesta este un fișier executabil complet în Visual FoxPro, dar necesită ca Visual FoxPro să fie executat direct. Poate fi apelat dintr-un alt executabil VFP care rulează deja în mediul de rulare.

Opțiunea de compilare a executabilului Win32 / server COM (.exe) efectuează toate acțiunile care sunt efectuate pentru executabilul aplicației. Apoi, fișierul aplicației trece printr-un proces metamorfic care adaugă codul de pornire necesar pentru a deveni un executabil Windows care apelează fișierele DLL necesare de rulare, adaugă pictograma și informațiile despre versiunea .exe. Executabilul generat va necesita fișierele de rulare VFP (Vfp6r.dll și Vfp6rXXX.dll (XXX reprezintă versiunea specifică a limbii)) pentru a rula în afara mediului de dezvoltare VFP. Un fișier Bibliotecă de tipuri este generat dacă în proiect există clase OLE Public.

Opțiunea de construire a serverului COM cu un singur thread (.DLL) și opțiunile serverului COM cu mai multe fire (.DLL) construiesc obiecte COM complete și fișierele necesare Bibliotecă de tipuri (.TLB) după ce parcurge procesul de reconstrucție. Fișierul Bibliotecă de tipuri este generat în același director ca și DLL. Aceste proiecte trebuie să aibă, de asemenea, clase marcate ca OLE Public. DLL-ul cu mai multe fire necesită un fișier special de rulare numit VFP6T.DLL. Toate serverele care sunt construite sunt adăugate la pagina Server din dialogul Informații despre proiect.
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Cum să utilizați opțiunile de proiect în avantajul dvs

Dialogul Informații despre proiect prezintă dezvoltatorilor detalii cheie despre proiect și fișierele care fac parte din proiect.

Prima pagină este fila Proiect. Acest formular permite dezvoltatorului să introducă informațiile despre adresa lor. Aceste informații sunt stocate în codul generat pentru meniuri. În afară de asta, este doar documentație pentru proiect. În zilele de 2.x, informațiile despre proiect au fost stocate și în codul de ecran generat. Mai important, această pagină oferă dezvoltatorilor acces la setările cheie pentru procesul de construire.
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Cum folosești setarea Informații de depanare a unui proiect?

Setarea Informații de depanare este critică în două situații. Primul este atunci când depanați o aplicație și urmăriți prin cod. Dacă codul nu a fost compilat cu informațiile de depanare activate (bifate), atunci veți primi un mesaj „Sursa este învechită” în fereastra de urmărire. Acest lucru poate fi cu adevărat agravant atunci când vă aflați la zece niveluri adânc în stiva de apeluri și ați lovit un program care a fost compilat fără codul de depanare. Urăm când se întâmplă asta!

Este esențial să rețineți că un fișier nu este compilat decât dacă se bifează Recompile All atunci când se face construirea sau dacă fișierul a fost modificat de la ultima versiune. Verificarea opțiunii Cod de depanare nu garantează că toate fișierele vor avea sursa compilată. Singura dată este când este marcat Rebuild All. A doua situație critică este atunci când construiți versiunea finală de livrare a aplicației.

Există o diferență semnificativă în dimensiunea executabilului între activarea și dezactivarea codului de depanare. Vă recomandăm să dezactivați această opțiune atunci când construiți codul care urmează să fie livrat odată cu lansarea. Dimensiunea poate fi de peste 10 ori mai mare cu codul inclus. Am avut un caz în care un .exe avea 50 de megaocteți cu codul sursă inclus pentru depanare și puțin peste 4 megaocteți fără acesta. Trimiterea codului cu codul de depanare setat pe livrează codul sursă în executabil. Acesta este modul în care fereastra de urmărire poate afișa fiecare linie în curs de executare. Rețineți că clientul sau alt dezvoltator va avea acces la acest cod dacă este expediat în arena de producție.
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Cum folosești setarea Criptată a unui proiect?

Acest lucru ne duce la setarea Criptată. Nu îți place cum toate acestea curg împreună? Setarea Criptată face ca executabilul generat să fie criptat, astfel încât alți dezvoltatori să nu aibă acces la codul sursă din interiorul executabilului. Este destul de inutil în mintea autorului, deoarece există instrumente terțe care vor decompila un executabil. Desigur, aceste instrumente terțe vă permit să ștampilați o cheie, astfel încât o altă copie a produsului să nu o poată decompila. Este mai degrabă ca și cum te-ai șantaja să cumperi produsul, nu-i așa? Pe de altă parte, instrumentul are o utilizare excelentă atunci când cineva pierde codul sursă sau dezvoltatorul original omite orașul, așa că ar putea merita cumpărat. De asemenea, executabilele criptate nu pot fi comprimate atunci când sunt arhivate pe baza schemei de criptare utilizate intern. Acest autor i-ar plăcea dacă Microsoft ar permite dezvoltatorului să introducă o cheie atunci când criptează executabilul pentru a ocoli instrumentele terțe și a face cu adevărat o setare valoroasă.

Caseta de text Last Built afișează data și ora la care a fost finalizată ultima construcție - un memento util despre când ați compilat ultima dată aplicația . Setarea projecthook este abordată în Capitolul 15, Project Objects și ProjectHooks.
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Cum setați o pictogramă personalizată pentru un executabil?

Acesta este un proces în doi pași. Primul este să atribuiți proprietatea _screen.icon fișierului pictogramă din programul principal de pornire. Al doilea este să utilizați dialogul Informații despre proiect pentru a atașa pictograma proiectului. Ce se întâmplă în timpul construirii proiectului cu această pictogramă? Ei bine, este stocat fizic în executabil. Acest lucru oferă Windows posibilitatea de a afișa pictograma aplicației dvs. personalizate în loc de pictograma drăguță vulpe. Spunem pictograma drăguță, deoarece am avut de fapt un client care a remarcat odată că nu a vrut să înlocuim capul de vulpe „drăguț” cu o altă pictogramă pentru aplicația sa <g>.

Fișierul ¡con (.¡co) poate stoca mai multe copii ale imaginii pictogramei. Fiecare dintre aceste imagini are o rezoluție diferită. Este important să editați ambele imagini, deoarece Windows utilizează o imagine de 16 x 16 pixeli pentru ferestrele aplicației și imaginea de 32 x 32 pixeli pentru afișarea unei imagini mai mari în aplicații precum Windows Explorer.

Vă recomandăm să obțineți unul dintre instrumentele de editare a pictogramelor, astfel încât să vă puteți crea propriile pictograme sau să modificați pictogramele pe care le cumpărați. Este foarte important să folosiți un editor de pictograme care poate edita ambele imagini. Folosim applet-ul Microsoft Imagedit.exe livrat cu VFP 5.0. Când o pictogramă este deschisă, sunteți întrebat de obicei care dintre imagini doriți să editați. Ar trebui să puteți selecta fie imaginea EGA/VGA 16 Color (32x32) fie imaginea Small Icon 16 Color (16x16). Dacă una dintre imagini lipsește din fișierul pictogramă, facem un „select all” pe imaginea care există și o copiem în clipboard. Deschidem cealaltă imagine din fișierul pictogramă și lipim conținutul clipboard-ului în editorul de imagini. A doua imagine va fi fie extinsă, fie micșorată. Ne place opțiunea de ajustare automată pe care ImageEdit o oferă atunci când extindeți sau micșorați graficul pentru a se potrivi noii dimensiuni.

Utilizarea corectă a pictogramelor poate lustrui o aplicație și îi poate conferi un aspect mai profesional. Una dintre cele mai simple modalități de a construi o colecție bună de pictograme este să achiziționați mai multe CD-ROM-uri cu imagini/pictograme de la terți. Există o mulțime de pictograme inutile pe aceste CD-uri, dar o pictogramă bună merită cu ușurință prețul întregului CD atunci când iei în considerare cât timp poți petrece creându-l pe al tău.
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Cum gestionați fișierele în Managerul de proiect?

Fila Fișiere cu informații despre proiect vă permite să sortați prin ListView care conține lista de fișiere. Aceasta înseamnă că dezvoltatorii pot sorta lista de fișiere după tipul fișierului, numele fișierului, ultima modificare, dacă este inclusă și pagina de cod. Făcând dublu clic pe „anteturi”, coloana va fi sortată. Acest dialog vă permite, de asemenea, să comutați dacă fișierul este inclus sau exclus din aplicația sau din versiunile executabile. Fișierele incluse arată un „X”, iar fișierele excluse afișează o casetă goală. Dacă caseta este umplută cu gri, aceasta indică fișierul principal pentru proiect. Fișierele care mențin o pagină de coduri pot fi, de asemenea, actualizate la pagina de cod nativă. Acest lucru este important pentru dezvoltatorii care creează aplicații care rulează în afara limbajului lor matern și/sau a paginilor de cod.
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Cum gestionați serverele din Managerul de proiect?

Fila Project Information Servers listează clasele din proiect, atât în Visual Class Libraries, cât și în fișierele program (prin codul DEFINE CLASS) care sunt marcate OLEPublic. Fiecare clasă disponibilă ca server este listată în caseta de listă din partea stângă a paginii. Pe măsură ce derulați în jos în listă, numele clasei, biblioteca clasei, descrierea, fișierul de ajutor și id-ul contextului de ajutor se schimbă pentru acea clasă specifică. Se pot face setări pentru a indica dacă serverul de automatizare este cu un singur fir, cu mai multe fire sau nu poate fi creat deloc prin opțiunea Instanțăre.

Acesta este un cadru important din perspectiva performanței. Serverele cu un singur thread au nevoie de o instanță pentru fiecare referință la clasă. Numai un proces poate fi apelat o dată la acea instanță.

Aceasta a fost o problemă înainte de Service Pack 3, când două procese trebuiau să acceseze metode separate într-un server, deoarece doar unul putea fi gestionat la un moment dat. Dacă aceasta este o problemă de performanță, serverul cu mai multe fire poate interveni și gestiona ambele apeluri cu o singură instanță. Informațiile Bibliotecă de tipări sunt, de asemenea, afișate în acest dialog.
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Cum setați descrierea obiectului proiectului?

Crearea documentației tehnice a fost întotdeauna o prioritate scăzută pentru majoritatea dezvoltatorilor pe care îi cunoaștem. Nu este unul dintre lucrurile distractive pe care le facem în meseria noastră. Fiecare fde care este urmărită în proiect are o descriere opțională care poate fi introdusă. Această caracteristică specială a Managerului de proiect este foarte utilă într-un mediu de echipă, astfel încât toți dezvoltatorii să poată înțelege ce realizează fde sau ce caracteristici le acceptă. De asemenea, poate fi util în magazinele cu o singură persoană pentru a reaminti dezvoltatorului care este scopul fde.

Descrierea poate fi accesată prin meniul contextual al Managerilor de proiect (meniul cu clic dreapta) sau prin opțiunea meniului principal Proiect|Editare descriere.... Această opțiune afișează dialogul Editare descriere (vezi Figura 14.1). Introduceți textul care descrie cartoful și salvați-l apăsând butonul OK. Desigur, apăsarea butonului Anulare va anula modificările pe care tocmai le-ați introdus.

Manager de proiect - SampleOI

AU | Date j Documente j Clase | Cod j Altele j |V|

± W

Codul bibliotecilor de clasă pentru documente de date

Alte meniuri „U

фО Fișiere text

П sampleOI È ffl Alte fișiere

Nou...

Adăuga...

Mcdify

Alerga

sampietri .htm sampietri rtf sampletn .ohm sampleOI. ppt sampietri. rds eşantionO2.p¡H

impleOI .doi

Elimina...

Construi...

Ж

æ

Descriere: Acest fișier este un exemplu de document Word 2000.

Calea: 	d:\data\winword\tipsbook\chapter14\ch14\sample01 .doc

Figura 14.1 Utilizarea descrierii fișierului pentru a descrie scopul fișierului în aplicație vă poate ajuta pe dvs. și colegii dvs. de echipă să înțelegeți pentru ce este aceasta, fără a deschide fișierul.

Mai multe fișiere păstrează descrierea în metadatele codului sursă al fișierului, altele sunt salvate în metadatele proiectului. Descrierile introduse în Managerul de proiect sunt păstrate în definițiile de clasă (nu la fel pentru bibliotecile de clasă), bazele de date, tabelele conținute și definițiile de vizualizare. Dacă descrierile sunt adăugate/modificate prin Clasa, Baza de date, Tabel sau View Designer, acestea sunt stocate în metadatele sursă și afișate în Managerul de proiect. Restul descrierilor sunt stocate direct în fișierul de proiect. Acest lucru este important să știți dacă aveți vreodată un fișier de proiect corupt. (Da, se întâmplă, deși mai rar decât în zilele 2.x.) Dacă nu păstrați copii de siguranță solide ale fișierelor de proiect și aveți unul corupt, veți pierde descrierile în timpul reconstruirii unui nou proiect.
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Cum să setați informațiile despre versiunea executabilă

Managerul de proiect Visual FoxPro 6.0 stochează cele mai recente informații despre versiune, care este configurată prin dialogul Build (a se vedea Figura 14.2). Aceste informații sunt folosite de procesul de construire și stocate în executabilul rezultat (.EXE). Trebuie remarcat faptul că nu este stocat în aplicația (.APP) fde dacă acesta este tipul de executabil pe care îl generați.

Manager de proiect - SampleOI

Eu....ÃH.І | Date | Documente | Clasele | Cod |

-

Altele | |~t~|

Des

Pati

Pati

9 Opțiuni de construcție

Build Options

Construiește acțiune

Г Proiect de reconstrucție

Bine

Г Flegenr

Opțiuni -

Г Reçom

f-" Aplica

P Win32

Г Șingle-t

C Multi-th

+

Figura 14.2 Folosind dialogul Opțiuni de compilare pentru a obține dialogul Versiune, dezvoltatorii VFP pot stoca informații direct în executabilul rezultat. Unele dintre aceste informații pot fi văzute în instrumente precum Windows Explorer

Informațiile despre această versiune pot fi extrase prin noua funcție nativă AF I LEVERS ION. Dacă dintr-un motiv oarecare utilizați VFP 5.0, va trebui să utilizați funcția GetFileVersion care este disponibilă în FoxTools.fll. Există unele diferențe în apelarea funcțiilor și informațiile din matricea fiecărei funcții, așa că dacă utilizați VFP 5.0, consultați Help fde.

În VFP 6, funcția AEILEVERSION returnează zero dacă fde specificată în al doilea parametru nu este găsit. Dacă se găsește fde, matricea este creată cu 15 elemente. Tabelul 14.1 conține informațiile care ar fi văzute prin executarea unei note de listă în fereastra de comandă:

?AGETFILEVERSION(laEXEDtalii, „Sample01.exe”)

Tabelul 14.1 - Exemplu de ieșire din AGETFILEVERSION din Sample01.exe

Poziția matricei 	Conținut Valori eșantion
1 	comentariu „Dezvoltat pentru 1001 de lucruri pe care ai vrut să le știi despre VFP”
2 	Numele companiei „Kirtland Associates”
3 	Descrierea fișierului „Aplicație cool”
4 	Versiunea fișierului „1.0.1”
5 	Nume intern „sample01”
6 	Drepturi de autor legale „Ianuarie 2000”
7 	Marcă legală „Eșantion de marcă comercială”
8 	Numele fișierului original „sample01 .exe”
9 	Construcție privată""
10 	Numele produsului „Sample.exe”
		

11 	Versiunea produsului „1.0.1”
12 	Construcție specială""
13 	OLE Self-Înregistrare""
14 	limbi „Engleză (Statele Unite)”
15 	Cod traducere „040904e4”

Funcția AFILEVERSION poate fi utilizată pentru a determina detaliile versiunii în mai mult decât doar aplicabile VFP; poate fi folosit și pentru a obține detalii despre versiuni pe alte executabile Windows. Prin urmare, dacă rulați următorul cod, veți primi 9.0.2719 ecou pe ecran pentru versiunea inițială a Excel 2000:

AGETFILEVERSION(laEXEDtalii, ;

„C:\Program Files\Microsoft Office\Office\EXCEL.EXE”)

?laExeDetalii[4]

Deci, la ce folosește această caracteristică? Îl folosim pentru a afișa informațiile despre versiune atât în ecranul nostru standard, cât și în fereastra Despre a aplicației.
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Care sunt avantajele includerii Config.fpw în proiect?

Fișierul Config.fpw permite dezvoltatorilor Visual FoxPro controlul asupra setărilor mediului VFP. Adăugarea fișierului la proiect permite editarea ușoară a setărilor aplicației. Marcarea acestuia inclusă în proiect va încorpora configurația în executabil. VFP folosește automat acest fișier pentru a face orice modificări de configurare pe măsură ce aplicația pornește. Dacă fișierul nu este marcat ca fiind inclus în proiect, acesta trebuie să fie distribuit separat cu executabilul.

Acesta este un exemplu de fișier Config.fpw care poate fi inclus în proiect. Setările din interiorul acestui fișier ar determina pornirea VFP fără ca ecranul principal să fie afișat și fișierul FoxUser din directorul de sistem din directorul rădăcină al aplicației să fie utilizat ca fișier de resurse pentru aplicații:

* Aplicația începe cu Cadrul VFP dezactivat

ecran = oprit

resursă = system\foxuser.dbf

Includerea fișierului în executabil va elimina necesitatea ca procesul de instalare să încarce un fișier de configurare și apoi să îl aloce prin mecanismele obișnuite. În trecut, s-ar putea să fi inclus într-un parametru -c pe linia de comandă într-o comandă rapidă pentru aplicație. Dacă utilizatorul a făcut dublu clic pe executabil în Windows Explorer, setările nu au fost niciodată făcute deoarece fișierul de configurare nu a fost încărcat niciodată. Celălalt mecanism este variabila de mediu FOXPROWCFG DOS, dar aceasta obligă personalul de asistență sau utilizatorul să se asigure că aceasta este configurată pe fiecare mașină pe care rulează executabilul. Celălalt dezavantaj al utilizării setării mediului DOS este că este fișierul de configurare implicit pentru toate aplicațiile VFP încărcate. Ne place să avem mai mult control pentru fiecare aplicație, atribuind astfel un fișier de configurare specific pentru fiecare sistem lansat.
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Cum putem include obiecte non-VFP în proiect?

Dezvoltatorii VFP sunt familiarizați cu diferitele tipuri de fde care sunt urmărite într-un proiect VFP standard, cum ar fi formulare, rapoarte, etichete, biblioteci de clase vizuale, programe, API-uri, aplicații, meniuri, fișiere text, baze de date și tabele gratuite. Știați că puteți include fișiere din procesorul de text, foaia de calcul, pachetul graphies sau altă aplicație preferată?

Există mai multe fișiere non-VFP pe care ne place să le includem în managerul de proiect pentru toate aplicațiile pe care le dezvoltăm. Dacă aveți Managerul de proiect configurat pentru a deschide fișierul atunci când faceți dublu clic, acesta funcționează la fel ca Windows Explorer și va declanșa programul asociat și va deschide fișierul. Ne place să includem aceste tipuri de fișiere non-VFP în categoria Alte fișiere din Managerul de proiect, deoarece arată extensia de fișier. Una dintre problemele cu această tehnică este că tipul de fișier implicit pentru această categorie este un bitmap (.bmp;.msk), iar restul tipurilor de fișiere din listă sunt grafice. Trebuie să selectați opțiunea „Ail Files” și să alegeți fișierul pe care doriți să îl adăugați la proiect.

Figura 14.3 Manager de proiect cu fișiere non-VFP incluse în proiect

Există câteva elemente demne de remarcat de menționat cu această funcționalitate. Dacă nu excludeți aceste fișiere, ele vor fi încorporate în executabilul generat în timpul procesului de construire. Sunt incluse implicit atunci când le adăugați. Acest lucru poate fi benefic dacă doriți ca acestea să fie livrate împreună cu produsul final și nu doriți să le trimiteți ca fișier separat. Partea negativă a monedei este că aceste fișiere vor adăuga dimensiunea completă de octeți a fișierului la executabilul tău. Aceste fișiere umflate pot duce la încărcare mai lentă a executablelor și la nevoia de mai multă memorie pentru a rula aplicația.

Primul fișier pe care ne place să îl avem ca parte a proiectului este un fișier ReadMe.txt. Acest fișier include orice detalii pe care personalul de dezvoltare trebuie să le includă pentru ca utilizatorii să le citească după ce încarcă cea mai recentă

revizuirea cererii. Acest fișier are o listă de funcții noi, remedieri de erori și probleme restante pentru versiunea pe care o lansăm. Acest lucru oferă bazei de utilizatori un punct de plecare pentru a înțelege ce trebuie să revizuiască, iar personalului de dezvoltare o modalitate de a urmări un istoric despre ceea ce s-a lucrat pentru lansare și ceea ce trebuie să fie finalizat înainte de a livra.

Al doilea tip de fișier pe care îl includem de obicei sunt fișierele de procesare de text. Există mai multe documente utilizate pentru managementul și dezvoltarea proiectelor în cadrul ciclului de viață al unui proiect. Acestea includ propuneri, specificații funcționale, ordine de control al modificărilor, liste cu priorități și documente OLE Automation. Adăugarea acestor fișiere la un proiect poate economisi timpul necesar pentru a găsi directorul în procesorul de text de fiecare dată când unul dintre aceste documente trebuie modificat. De asemenea, ar fi prudent să menționăm că aceste fișiere ar trebui gestionate îndeaproape și în afara proiectului, deoarece sunt importante pentru succesul proiectului.

Fișierele de ajutor pot fi incluse indiferent dacă sunt formatul HLP mai vechi sau formatul HTML compilat mai nou (CHM). Acest lucru oferă dezvoltatorilor de proiect acces la fișierul de ajutor generat fără a porni aplicația.

Fișierele HTML pot fi modificate folosind editorul VFP nativ, dar există instrumente mai bune care modifică acest tip de fișier. Dacă aveți extensia HTM atribuită unui instrument precum FrontPage sau Hot Metal sau dacă utilizați implicit un browser precum Netscape Navigator sau Internet Explorer, aceste fișiere vor fi deschise în afara Visual FoxPro.

Chiar dacă fișierele de proiect sunt native pentru Visual FoxPro, ele pot fi adăugate la un proiect ca alt fișier. Sună cam ciudat, nu-i așa? Făcând dublu clic pe acest fișier, proiectul va fi deschis în propria instanță a Managerului de proiect. Dacă arhitectura pe care ați selectat-o are un executabil principal și mai multe aplicații care sunt executate din executabilul principal, puteți configura proiectul de control și aveți proiectele „aplicații” disponibile din interiorul acestuia.

Nu există practic nicio limită pentru numărul de fișiere externe care fac parte din fișierul de proiect, ci doar limita de 2 gigabyte a dimensiunii fișierului din tabelul de metadate ale proiectului. Singura cerință este ca fișierul adăugat trebuie să aibă o extensie de fișier înregistrată care este asociată cu un program. Vă încurajăm să utilizați această funcționalitate atunci când o considerați potrivită.

Copyright 2000 de către Marcia Akins, Andy Kramek și Rick Schummer Toate drepturile rezervate

Cum să reduceți imobilul pe ecran luat de managerul de proiect

Funcționalitatea de andocare este de obicei asociată cu barele de instrumente. Mulți dezvoltatori VFP noi nu au fost introduși în capacitatea de andocare a Managerului de proiect VFP, deoarece o văd ca pe un formular pe desktop. Managerul de proiect poate fi o formă completă sau poate fi redus la o existență asemănătoare unei bare de instrumente. Aceasta poate fi comutată făcând clic pe butonul de comandă săgeată din dreapta filelor.

Managerul de proiect este andocat numai atunci când este tras în bara de instrumente/zona de meniu de sus a mediului de dezvoltare sau făcând dublu clic pe Bara de titlu a managerului de proiect (cunoscută și ca formularul Caption). Singura modalitate de a închide un proiect andocat este folosind opțiunea de meniu Fișier|Închidere. De asemenea, puteți dezaoca proiectul pentru a-l închide prin butonul de închidere.

I...AII.ț j Date | Documente |

Clasele | Cod | Altele |

±

Dat.



Documente

Biblioteci de clasă

Cod Alte meniuri „Щ”.

- П Fișiere text ΓΊ eșantionOI

É И Alte fișiere sampleOI .doc sampleOI .htm sampleOI. rtf sampleOI .ehm sampleOI. ppt mostOI. xls sample02.p¡x

Figura 14.4 Așa arată managerul de proiect atunci când este andocat la o bară de instrumente și una dintre pagini este accesată făcând clic pe fila pagină
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Cum să rupeți filele din Managerul de proiect

Comprimatele de rupere nu au nimic de-a face cu băutura ta rece preferată. Ei bine, s-ar putea dacă aveți niște cutii de modă veche, dar când se referă la Visual FoxPro, filele rupte au de-a face cu Managerul de proiect care a fost redus la starea sa asemănătoare barei de instrumente. Faceți clic pe pagina dorită, apoi trageți fila paginii din bara de instrumente. Aceasta va lăsa fila pe desktop.

Odată ce fila a fost scoasă din bara de instrumente, o puteți trage oriunde doriți pe desktopul VFP. VFP își amintește unde ați lăsat proiectul când acesta este închis, dar din anumite motive nu salvează starea paginilor. Prin atingerea colțului din dreapta jos al filei vă permite să o dimensionați la fel ca o fereastră obișnuită de dimensiuni mari. Tragerea oricăreia dintre laturi nu poate face acest lucru - trebuie să fie colțul. Închiderea și redeschiderea proiectului reatașează filele care au fost eliminate anterior. Făcând clic pe agraful va comuta actorul. Aceasta ar trebui să se blocheze unde se află fila, astfel încât să nu o puteți trage nicăieri până când nu este din nou comutată „în afara”. În VFP 6.0 cu Service Pack 3 aplicat, agraful nu are niciun efect asupra capacității de tragere.

Cod

|C| Biblioteci API J* Aplicații

Dati

Λ

Biblioteci de clasă Documente

Cod Altele TT M enus

- 	ΓΊ Fișiere Tewt

Q eșantionCH

- 	gg Alte fișiere sampleCH .doc sampleCH .htm sampleCH. rtf sampleCH .ehm sampleCH. ppt eșantionCH. :-:ls sample02.p¡x

Figura 14.5 Iată un exemplu de proiect al acestui capitol cu paginile Ail și Code rupte

Puteți extinde Managerul de proiect la dimensiunea completă chiar și cu filele dezactivate. Paginile care sunt dezactivate sunt dezactivate și rămân dezactivate. Puteți întoarce filele înapoi la Managerul de proiect, fie în dimensiune extinsă, fie în dimensiune redusă, trăgându-le înapoi, dar le puteți rupe numai când Managerul de proiect este în starea redusă.
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Ce probleme există la deschiderea unei baze de date în proiect?

Un lucru pe care l-am învățat devreme și adesea este că proiectul deschide automat orice baze de date care au ierarhia extinsă în filele Date sau Toate, prima dată când fiecare filă primește focus. Dacă proiectul a fost închis când fila Date avea focus, se va deschide orice baze de date care sunt extinse atunci când proiectul este deschis.

Bazele de date sunt deschise exclusiv sau în mod partajat, pe baza setărilor de mediu ale set exclusive. Acest lucru poate fi critic dacă se dezvoltă într-o situație de echipă care nu utilizează o formă de control al codului sursă cu copii ale aceluiași proiect cu nume diferite. Acest autor s-a luptat prin asta cu echipa sa până când a instituit o clasă projecthook care SETĂ EXCLUSIV OFF atunci când proiectul se deschide. În acest fel, toată lumea din echipă poate juca în același sandbox fără a bloca accesul la bazele de date. Dacă un dezvoltator folosește exclusiv baza de date și altul deschide fila de date, Managerul de proiect încearcă să scoată diferite detalii din baza de date, dar nu poate citi baza de date. Intră în modul „mișcare lentă” și desenează încet TreeView doar cu nodurile native pentru VFP. Nu sunt afișate tabele, vizualizări, conexiuni sau proceduri stocate. O altă problemă cu acest mod este că nimeni altcineva nu poate construi o aplicație, deoarece Managerul de proiect are nevoie de utilizarea exclusivă a bazei de date pentru a recompila procedurile stocate. Nu suntem siguri de ce este necesar acest lucru, deoarece acestea sunt compilate de fiecare dată când sunt salvate după o sesiune de editare.

Dacă baza de date este deschisă prin Project Manager, aceasta nu poate fi închisă cu comanda CLOSE DATABASES ALL. Comanda realizează efectiv un SET DATABASE TO, ceea ce face ca nicio bază de date să fie baza de date curentă. Singura modalitate de a închide bazele de date deschise prin Managerul de proiect este să selectați baza de date și să apăsați butonul de închidere al Managerului de proiect sau să închideți proiectul.
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Trucuri de glisare și plasare a proiectelor

Mulți dezvoltatori sunt surprinși să afle că Managerul de proiect este un client și un server drag-n-drop. Aceasta înseamnă că fișierele pot fi trase în Managerul de proiect din mai multe surse, inclusiv din alte proiecte și din afara Visual FoxPro.

Ce se întâmplă când treceți de la un proiect la altul?

Tragerea fișierelor între două proiecte diferite creează o referință în al doilea proiect pentru acel fișier. Dacă există o descriere pentru fișier, această descriere este adăugată și la al doilea proiect, chiar și pentru fișierele care nu stochează descrierea în fișierul în sine. Dacă fișierul este un program setat ca program principal al proiectului inițial, VFP vă va solicita o întrebare care vă va întreba dacă doriți să faceți din fișier programul principal în al doilea proiect. Nu trebuie să fiți pe aceeași pagină în fiecare proiect. Fișierul este adăugat în mod natural la categoria corectă în funcție de extensia de fișier.

Cum trag obiecte dintr-un proiect la un designer?

Tragerea fișierelor din proiect într-un designer de formulare sau de clasă poate economisi timp în timpul dezvoltării. Multe obiecte de proiect pot fi trase în Form sau Class Designer. Obiectele aruncate sunt instanțiate în designer.

Tragerea unui câmp dintr-un tabel, vizualizare sau tabel liber din baza de date într-un formular sau clasă va instanția clasa asociată pentru tipul de date. Avantajul acestei caracteristici este că creează un obiect legat în clasă fără utilizarea unui mediu de date. Mulți dezvoltatori pe care i-am instruit de-a lungul anilor simt că trebuie să urmeze mai întâi o clasă și apoi să seteze ControlSource. În timp ce setarea manuală a ControlSource funcționează, necesită dezvoltatorilor să efectueze un pas suplimentar. Celălalt avantaj al acestei tehnici este că încorporează capacitatea IntelliDrop văzută atunci când efectuați această operație din mediul de date. În acest fel sunt folosite clasele specificate în prealabil în locul claselor de bază VFP.

Tabelele trase într-o formă sau clasă vor instanția o grilă. Dacă faceți clic dreapta și glisați, vi se prezintă opțiunea clasei grilă (sau altă clasă pe care ați setat-o pentru setarea Multiple în Maparea câmpurilor din Instrument|Opțiuni).

Dacă doriți ca o anumită clasă să fie plasată pe o altă clasă de container, o puteți selecta în Managerul de proiect și o puteți trage în clasa containerului. Acest lucru nu leagă obiectul ca operația de glisare a unui câmp de tabel. Acest lucru vă permite să suprascrieți setările IntelliDrop care sunt pre-mapate.

Ne-am așteptat ca o pictogramă aruncată într-un formular să stabilească proprietatea Icon Icon și ca aruncarea unui grafic să genereze un obiect imagine. Ei nu. Alte obiecte care nu sunt menționate în această secțiune nu pot fi aruncate într-o clasă de formular sau de container.

Ce se întâmplă când trageți de la proiect la codul programului?

În același spirit descris în secțiunea precedentă, puteți glisa și plasa diferite obiecte de proiect în editorii de cod. Numele obiectului este afișat în fereastra de cod. De exemplu, dacă renunțați la un

numele câmpului în fereastra de comandă, obțineți numele câmpului. Din păcate, nu obțineți sintaxa table.fieldname. Acest lucru funcționează pentru fiecare tip de obiect din proiect, cu excepția numelor de proceduri stocate. Singurele obiecte care transportă extensia de fișier sunt fișierele din categoria „altele”.

Ce se întâmplă când trageți din Class Browser sau Component Gallery într-un proiect?

Am testat alte câteva idei cu această capacitate, trăgând fișiere din browserul de clasă VFP și vărul său apropiat, Galeria de componente.

Ne așteptam ca tragerea claselor din Browserul de clasă în Managerul de proiect să adauge clasa. Din păcate, acest lucru nu funcționează. Am tras pictograma din colțul din stânga sus către proiect, la fel cum am făcut de multe ori într-o altă instanță a browserului de clasă. Nu funcționează în versiunea de VFP 6.0 pe care o rulăm, care este Service Pack 3.

Și mai interesant este că efectuarea acelorași teste în Galeria de componente s-a dovedit a fi de succes. Alegeți clasa din Galeria de componente și trageți pictograma în colțul din stânga sus sau pictograma din panoul din dreapta și trageți-o în Managerul de proiect. Dacă fișierul este o clasă, este prezentat un dialog care vă întreabă cum doriți să adăugați fișierul la proiect (vezi Figura 14.6). Aveți opțiunea de a adăuga biblioteca de clasă existentă sau de a adăuga o copie a clasei la o altă bibliotecă de clasă. Fișierul este adăugat. Misto! Orice fișier care poate fi adăugat la un proiect poate fi aruncat din Galeria de componente. Adăugarea rapidă a fișierelor comune la un proiect din catalogul tău preferat este o tehnică destul de puternică!

Figura 14.6 Iată caseta de dialog Adăugați o clasă la proiect, care este prezentată atunci când aruncați fișiere din Galeria de componente într-un proiect

Ce se întâmplă când trageți dintr-o aplicație non-VFP într-un proiect?

O altă capacitate grozavă este că fișierele pot fi trase în Managerul de proiect din afara VFP. Managerul de proiect este doar una dintre multele părți ale VFP care au fost activate pentru OLE Drop and Drag în VFP 6.0.

Deci, cum pot folosi această funcție? Deschideți Windows Explorer sau înlocuitorul dvs. preferat. Dacă glisăm și plasăm fișierele specifice VFP din Explorer în Managerul de proiect, acestea sunt adăugate la categoria corespunzătoare. Fișierele non-VFP sunt adăugate la categoria „altele”. Dacă tragem o comandă rapidă de pe desktop, obținem un fișier de scurtătură (.LNK) adăugat la categoria „altele” din Managerul de proiect.
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Cum să profitați de câmpul utilizator al proiectului

Fiecare dintre fișierele de metadate Visual FoxPro conține un câmp de utilizator care nu este folosit deloc de VFP însuși. Este conceput pentru a fi folosit de dezvoltatori în orice scop consideră potrivit. Acest câmp nu este expus de interfața Manager de proiect, dar poate fi accesat deschizând metadatele proiectului ca tabel și răsfoindu-l.

Nu am întâlnit mulți dezvoltatori care folosesc această funcționalitate în fișierul de proiect. O utilizare la care ne-am gândit în ultimul timp este stocarea ultimei ștampile date/ora pentru copierea de rezervă în acest câmp și conectarea la un proces care arhivează toate fișierele din proiect într-un fișier comprimat prin DynaZip. Din păcate, actualul obiect Fișiere nu expune acest câmp dezvoltatorului în acest moment și procesul de backup va trebui să „pirateze” fișierul de proiect.
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Cum se procedează la documentarea fișierului de proiect

Până când proiectul ne-a fost dat în VFP 6.0, singura modalitate de a accesa informațiile despre proiect a fost să deschidem fișierul de proiect ca tabel și să procesăm înregistrările. Este foarte important să rețineți că ar trebui să procesați printr-o copie a fișierului original al proiectului. Această precauție este necesară în cazul în care faceți o modificare accidentală a unui câmp care derutează Managerul de proiect și dezactivează posibilitatea de a-l deschide.

Hackerea fișierului de proiect nu este o problemă atât de mare pe cât ar putea suna inițial, deoarece fișierul de proiect este bine documentat în ce altceva, un proiect, care se află în directorul ижо+чие>рес\·. Consultați Tabelul 14.2 pentru o listă de proiecte pentru fiecare dintre versiuni.

Tabelul 14.2 - Lista de specificații disponibile pentru aspectul fișierului de proiect VFP

Rapoarte de proiectVersiuni VFP	
60Spec.pjx 	60Pjx1 .frx 60Pjx2.frxVFP 6.0
50Spec.pjx 	50Pjx1 .frx 50Pjx2.frxVFP 5.0
30Spec.pjx 	30Pjx1.frx 30Pjx2.frxVFP 3.0
26Spec.pjx 	26Pjx1.frx 26Pjx2.frxToate versiunile VFP

În zilele de 2.x, autorul a creat un instrument de dezvoltare numit Project Lister. Acest instrument a fost creat inițial pentru a genera o listă de verificare a tuturor fdes-urilor dintr-un proiect pentru a procesa toate fdes-urile pentru documentare sau pentru a face modificări pentru o anumită actualizare. Acest instrument a evoluat de-a lungul anilor și este inclus ca exemplu de ceea ce puteți face atunci când „pirați” proiectul. Este disponibil în fdes de descărcare pentru dezvoltatori la www.hentzenwerke.com. Fde-ul se numește pl60.zip și este inclus cu celelalte fdes asociate cu acest capitol.

Figura 14.7 Acesta este lista de proiecte VFP, care este un exemplu de „piratare” a fișierului de proiect VFP

Utilitarul Project Lister listează diferitele obiecte sursă care se află într-un anumit proiect VFP. După cum sa menționat, acest instrument a fost creat pentru a enumera fiecare dintre obiectele din proiect ca o listă de verificare pe măsură ce o aplicație era în curs de dezvoltare. Pe măsură ce timpul a trecut, au fost adăugate din ce în ce mai multe funcții pentru a oferi mai multe detalii despre fiecare dintre obiecte. Acum, Project Lister este folosit pentru a documenta elementele de bază despre proiectele dezvoltate și pentru a determina ce anume este în proiectele pe care căutăm să le preluam. Încarnarea actuală nu numai că analizează diferitele obiecte de cod sursă, dar face și o treabă rudimentară decentă de a documenta un container de bază de date. Vă rugăm să rețineți că nu vă va oferi profunzimea pe care ți-o oferă ceva de genul Stonefield Database Toolkit, dar este util.

Tabelul 14.3 Caracteristici care sunt incluse în Lista de proiecte

Selectați proiectul de documentat dintr-un proiect deschis sau unul care se află pe disc

Rapoartele configurabile vă permit să selectați ce informații apar

Lista configurabilă de obiecte de proiect vă permite să selectați ce tipuri de obiecte apar în rapoarte

Poate răsfoi obiectele care vor apărea în ieșire

Selectați dintre mai multe rapoarte (atât tipărite mari, cât și comprimate) și comenzi diferite

Ieșire în raport de previzualizare, raport tipărit, fișier text, clipboard Windows sau format gratuit de tabel

Necesită VFP 6 deoarece încorporează unele dintre noile proprietăți, evenimente și metode ale obiectului proiectului
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Concluzie

Managerul de proiect al Visual FoxPro vă oferă o singură locație pentru a gestiona toate fațetele dezvoltării proiectelor și creării de construcție. Cu toate acestea, cu Visual FoxPro 6.0, Managerul de proiect este încă doar jumătate din poveste. De dragul lizibilității, „restul poveștii” despre proiecte, obiecte de proiect și cârlige de proiect sunt tratate în capitolul următor. Citește mai departe!
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Capitolul 15 - Obiecte de proiect și cârlige de proiect

„Nu am văzut încă vreo problemă, oricât de complicată, care, atunci când ai privit-o în mod corect, nu a devenit și mai complicată”. (Paul Anderson scrie în „New Scientist (Londra,” 25 septembrie 1969)

Acest capitol va prezenta noile obiecte ProjectHook și Project din VFP 6.0 și câteva utilizări ale acestor instrumente importante pentru dezvoltatori. Încheiem cu un exemplu care leagă atât proiectul VFP, cât și obiectul proiect într-un utilitar cunoscut sub numele de RAS Project Builder.

Este de părerea autorului că combinația dintre projecthook și obiectul de proiect a fost una dintre cele mai interesante caracteristici din lansarea Visual FoxPro 6.0. Aceste două caracteristici expun evenimentele managerului de proiect și extind capacitatea unui dezvoltator de a adăuga la mediul de dezvoltare interactiv (IDE) al Visual FoxPro. Projecthook este o clasă de bază VFP care permite rularea codului personalizat ca răspuns la acțiunile întreprinse de dezvoltator atunci când folosește Managerul de proiect. Obiectul Proiect este un obiect COM care permite dezvoltatorilor să efectueze acțiuni care au fost reglementate anterior pentru a „pirata” fișierele de proiect (.PJX).
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Cum să folosiți ProjectHooks pentru a prinde un pește mare

Mai întâi dorim să abordăm noua clasă de proiecthook. Projecthook-ul poate fi subclasat și extins la fel ca și celelalte clase de bază din VFP. Această clasă, atunci când este instanțiată, se conectează la diferite evenimente care sunt declanșate de managerul de proiect. Projecthook-ul este instanțiat opțional atunci când un proiect este deschis. Este important de remarcat că proiectele nu sunt automate; acestea vă cer să specificați o clasă projecthook pentru fiecare proiect.

Crearea unei clase projecthook este la fel de simplă ca și crearea oricărei alte clase în Visual FoxPro. Folosind comanda CREATE CIAS S apare dialogul New Class prezentat în Figura 15.1. Specificați numele clasei, îl bazați pe proiecthook VFP (sau altă clasă projecthook pe care ați creat-o anterior) și selectați biblioteca de clase pe care doriți să o salvați.

Figura 15.1 Dialogul VFP New Class care demonstrează cum se creează o nouă clasă projecthook

După ce faceți clic pe butonul OK, noul proiect hook va fi disponibil în Class Designer. Puteți consulta Foaia de proprietăți pentru a vedea toate proprietățile și metodele disponibile. Există o listă completă de metode în Tabelul 15.1.

Tabelul 15.1 Aceasta este o listă de metode și utilizarea lor pentru clasa projecthook.

Metoda 	de utilizare
AfterBuild 	Permite dezvoltatorului să verifice numărul de erori găsite în timpul acțiunii de construire. Acesta este, de asemenea, un loc minunat pentru a reseta mediul la setările salvate înainte ca acestea să fie setate în metoda BeforeBuild.
BeforeBuild 	Permite dezvoltatorilor să oprească o construcție pe baza condițiilor sau a parametrilor doriti. De asemenea, un loc pentru a pune cod pentru a solicita dezvoltatorilor posibile setări și pentru a ajusta mediul pentru construcție.

Distrugeți 	metoda standard VFP Destroy.
Eroare 	Metoda de eroare VFP standard.
Init 	Metoda standard VFP Init.
OLEDragDrop 	Metoda standard VFP OLEDragDrop.
OLEDragOver 	Metoda standard VFP OLEDragOver.
OLEGiveFeedBack 	Standard VFP Metoda OLEGiveFeedBack.
QueryAddFile 	Se declanșează atunci când un fișier nou de orice tip este adăugat la proiect. Codul poate fi inclus pentru a certifica faptul că fișierul poate fi adăugat la proiect. Include logica care efectuează un NODEFAULT, astfel încât fișierul să nu fie adăugat la proiect.
QueryModifyFile 	Se declanșează atunci când un fișier existent de orice tip este selectat pentru a fi modificat din proiect. Poate fi inclus un cod care va certifica ca fisierul poate fi modificat din proiect. Include logica care efectuează un NODEFAULT, astfel încât fișierul să nu fie modificat prin proiect.
Q ueryRemo veFile 	Se declanșează atunci când un fișier existent de orice tip este selectat pentru a fi eliminat din proiect. Opțional, puteți șterge și fișierul de pe disc. Poate fi inclus un cod care va certifica că fișierul poate fi eliminat din proiect. Include logica care efectuează un NODEFAULT, astfel încât fișierul să nu fie eliminat din proiect.
QueryRunFile 	Se declanșează atunci când un fișier existent de orice tip este selectat pentru a fi rulat din proiect. Poate fi inclus un cod care va certifica că fișierul poate fi rulat din proiect. Include logica care efectuează un NODEFAULT, astfel încât fișierul să nu fie rulat din proiect.

Odată creat hook-ul de proiect, acesta este pur și simplu desemnat ca hook-ul proiectului prin intermediul casetei de dialog Info proiect (vezi Figura 15.2). Opțiunea se află pe pagina Proiect și este selectată bifând caseta de selectare Clasă de proiect și trecând prin dialogul Referință proiect (dialog de selecție a clasei). Trebuie să știi că această clasă este un projecthook. Dacă nu selectați un projecthook, veți fi pedepsit cu un mesaj care spune exact asta.

Odată ce ați selectat cu succes clasa projecthook, este important să vă amintiți că trebuie să redeschideți un proiect, astfel încât projecthook-ul să fie instanțiat. Managerul de proiect nu este capabil să instanțieze clasa după ce este desemnată, decât dacă efectuați această acțiune.

w Manager de proiect - SampleOI

Date

Autor:

Abordare:

Oraș:

Țară:

Proiect

Abordare:

Ultima construită:

Companie:
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Documente
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Figura 15.2 Dialogul de selecție a cârligului de proiect VFP - arată ciudat de asemănător cu dialogul de selecție a clasei prezentat de funcția VFP AGETCLASS

Cum să configurați un ProjectHook global pentru toate proiectele

Pe lângă configurarea unui projecthook pentru un proiect individual, dezvoltatorii pot avea un projecthook ca proiect implicit pentru toate proiectele noi care sunt create în viitor. Acest lucru este configurat prin dialogul Instrumente VFP|Opțiuni din pagina Proiecte.

Când un proiect nou este creat, i se atribuie un proiecthook global. Aproape pare că ne luăm o cauză pentru a salva planeta. Dar serios, dacă ai dezvoltat un proiecthook care este de natură generică, atunci acesta este biletul tău.

Ce se întâmplă când un ProjectHook este pierdut sau șters?

Deci, vă întrebați ce se întâmplă dacă aveți un proiect hook desemnat pentru proiect și ceva merge prost. S-a întâmplat. Cineva intră și sparge nevinovat biblioteca projecthook și toastează fișierul. Sau mai rău - cineva schimbă în mod intenționat un cod, sperând să adauge cel mai bun lucru

deoarece pâinea feliată și face ca clasa să nu mai instanțieze. Sau ce se întâmplă dacă clasa este ștearsă din biblioteca clasei? Ce se întâmplă cu proiectul? Simplu - proiectul nu se deschide. Știu că vă gândiți că aceasta este o caracteristică de securitate ingenioasă de dezlănțuit pentru a împiedica dezvoltatorii juniori să intre în proiect cu o zi înainte de lansare. Ei bine, dacă sunt la fel de clari ca dezvoltatorii cu care lucrăm, ei vor deschide fișierul Ajutor sau această carte și vor vedea că proiectul poate fi deschis fără proiecthook. Comanda MODIFY PROJECT acceptă o clauză NOPROJECTHOOK. Iată un exemplu:

MODIFICA PROIECTUL d:\devvfp6apps\bookproject\tips.pjx NOPROJECTHOOK

Şobolani, cred că va trebui să restricţionăm în continuare autentificarea acelor dezvoltatori juniori cu o zi înainte de lansare <g>.

Dacă creați un proiect nou la care credeți mai bine și decideți să-l renunțați, VFP vă va solicita cu un mesaj în care vă va întreba dacă doriți să eliminați fișierele de proiect sau să le păstrați. Dacă configurați un projecthook global și parcurgeți acest scenariu, nu vi se va solicita deoarece VFP adaugă referința de clasă projecthook în fișierul de proiect și nu mai este gol.

Deci, ce poți face cu această capacitate puternică? În realitate, poți face aproape orice îți dorește inima. Mai târziu în acest capitol, există câteva secțiuni care detaliază implementările propriilor idei, precum și ideile altor dezvoltatori pe care i-am încorporat în proiectul nostru.

Ce a lăsat Microsoft din prima lansare a ProjectHooks?

Ce lipsește? În primul rând, o metodă de activare și dezactivare a proiectului ar fi foarte utilă. Le avem într-un utilitar pentru a controla modificările necesare pe măsură ce utilizatorul selectează un nou proiect. Veți vedea exemple mai târziu în acest capitol care modifică setările Field Mapping în registry atunci când proiectul este deschis. Dacă deschideți mai multe proiecte în timpul unei sesiuni în VFP, ultimele Mapări de câmp înregistrate sunt utilizate atunci când plasați și trageți câmpurile din mediul de date în formular. Dacă proiectele folosesc biblioteci de clasă separate, veți obține o „polenizare încrucișată” a bibliotecilor de clasă din proiecte. În biroul nostru, avem o subclasă a claselor de bază cadru pentru fiecare proiect și câțiva dintre dezvoltatorii noștri lucrează la proiecte diferite în fiecare zi. Deoarece folosim proiectul descris mai târziu în capitol, proiectele trebuie să fie exterminate de „clasele străine” din alte proiecte în mod regulat, deoarece dezvoltatorii care schimbă intens codul au tendința de a uita de confuziile Field Mapping.

Există un exemplu de proiect hook care este livrat cu Visual FoxPro 6.0. Exemplul arată cum puteți valorifica diferitele evenimente și puteți urmări activitățile pe care dezvoltatorii le desfășoară cu proiectul, scriind o intrare de fiecare dată când un fișier este modificat sau rulat sau proiectul este deschis sau construit. Acest lucru permite de asemenea vizualizarea activității atunci când proiectul este închis. Nu este un exemplu prea sofisticat, dar este eficient în demonstrarea puterii acestor clase. Această clasă și formularul exemplu pot fi

găsit în directorul HOME(5)+"soiution\tahoe\". Fișierele includ formularul exemplu numit acttrack.scx/sct și projecthook real, care se numește activity_tracker și se află în project_hook.vcx.
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Cum se accesează informațiile din obiectul Proiect și fișiere

Obiectul de proiect este încorporat în Visual FoxPro și nu poate fi subclasat. Este o interfață COM pentru fișierul de proiect. În trecut, dezvoltatorii trebuiau să „pirateze” fișierul de proiect, deschizându-l ca tabel gratuit VFP prin comanda de utilizare. Utilizarea comenzii SQL-Select și a proiectului deschis ca tabel liber este o combinație puternică pentru extragerea informațiilor care sunt stocate în metadate. Deși unele dintre aceste tehnici sunt încă utile, obiectul proiectului reduce nevoia de a „hack” metadatele proiectului.

Există o diferență în accesarea interfeței COM la proiect față de modul standard pe care ați putea fi obișnuit să îl utilizați. Obiectele COM sunt instanțiate prin intermediul funcțiilor createoboecto, createoboectexo sau NEWOBJECT() . Obiectul proiect este creat pentru dvs. de fiecare dată când este deschis un proiect. Obiectul proiect este creat pentru fiecare proiect deschis și este accesat prin obiectul aplicației _vfp. Acest obiect vă oferă acces la mai multe proprietăți și metode pentru a obține informații despre proiect. Iată un cod care accesează informații cheie din proiect:

CU _vfp.ActiveProject

? .VersionNumber && Afișează următorul număr al versiunii versiunii

? .MainFile && Afișează numele (și calea) fișierului principal

.CleanUp() && Ambalează metadatele proiectului

SE TERMINA CU

Colecția de fișiere a obiectului proiectului este modul în care se obține acces la fișierele individuale din cadrul proiectului. Există o serie de proprietăți care sunt asociate fiecărui fișier. Există și comportamente care pot fi apelate pentru a manipula fișierele din proiect. Iată un cod care accesează informații cheie dintr-un fișier din proiect:

CU _vfp.ActiveProject

? .Fișiere[1].Descriere && Afișează descrierea primului fișier

? .Files[1].Modify() && Modifică primul fișier în designerul nativ

SE TERMINA CU

Atât proprietățile proiectului, cât și ale obiectului fișier pot fi setate la fel ca orice altă proprietate a obiectului VFP printr-o instrucțiune de atribuire:

_vfp.ActiveProject.Files[1].Exclude = .T.

Prin aceste două obiecte COM, avem control aproape complet asupra tuturor fișierelor din proiectele noastre VFP.
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Cum să utilizați obiectele de proiect în dezvoltare

Este întotdeauna plăcut să obții o mulțime de teorii și de bombăniri despre cum funcționează lucrurile, dar nu există nimic ca să ai niște exemple din viața reală pentru a aduce totul împreună. Asta va face această secțiune. Majoritatea exemplelor fac tehnica „lista fișierele dintr-un proiect”. Deși considerăm că aceste exemple sunt valoroase, ele nu sunt foarte utile în mediul nostru de dezvoltare.

Cum să construiți un expert de bază pentru aplicații

Mai întâi vom demonstra piese dintr-un vrăjitor de aplicație în care obiectul proiectului și obiectul fișiere sunt exploatate. Un exemplu pe care l-am dezvoltat care folosește atât obiectul Proiect, cât și obiectul Fișiere este un expert pentru aplicații. Conceptul este destul de simplu. Procesați toți pașii mecanici pe care i-am făcut pentru fiecare lansare a dezvoltării unui nou proiect. Unii dintre voi s-ar putea să vă întrebați de ce treceți prin tot acest efort când VFP vine cu un expert pentru aplicații? Motivul este simplu - nu acceptă cadrul nostru și nu a îndeplinit nevoile arhitecturii noastre de implementare.

Procesul de construire manual a proiectului inițial a durat un dezvoltator câteva ore pentru a fi finalizat.

Folosind expertul pentru aplicații, acum durează toate zece minute. Iată pașii de bază implicați:

1. 	Creați directorul de proiect și toate subdirectoarele necesare/standard

2. 	Subclasele Framework până la nivelul clientului, apoi la nivel de proiect

3. 	Generați programul principal și programul compilator „faker”.

4. 	Generați fișierul Config.fpw

5. 	Copiați șablonul de meniu de pornire

6. 	Generați baza de date cadru și tabelele asociate

7. 	Adăugați tabele personalizate de extensie a cadrului

8. 	Generați mesele gratuite necesare

9. 	Subclasa phkDevelopment projecthook pentru proiect și setați proprietățile cheii

10. 	Completați tabelul Field Mapping Option Utility cu înregistrările necesare

11. 	Generați fișierul Proiect și completați cu fișierele necesare

12. 	Efectuați inițial Build the project

13. 	Trimiteți un mesaj dezvoltatorului pentru a începe să lucrați cu adevărat <g>

Codul folosit pentru a subclasa proiecthook și pentru a modifica proprietatea cFieldMappingCategory din mers la pasul nouă este demonstrat în Lista 15.1. Aceasta utilizează două tehnici care ar putea avea nevoie de explicații. Primul este CREATE CLASS... ASTEPTĂ ACUM. Această comandă creează clasa și o afișează în Class Designer, apoi continuă. Următorul fragment de cod folosește o tehnologie „builder” cu comanda ASELOBJ. Aceasta returnează o matrice cu o referință la obiect la projecthook din Class Designer. O declarație simplă de atribuire și cârligul de proiect este gata să se încadreze la standardele din magazinul nostru. Al doilea bit de explicație necesar sunt comenzile KEYBOARD și DOEVENTS. Designerul trebuie să fie închis și Ctrl-W este comanda rapidă „salvare fără a mă întreba dacă sunt cu adevărat sigur”. Deoarece toate acestea se întâmplă în cod și din moment ce tamponul tastaturii este un eveniment Windows, doevents a fost adăugat pentru a face ca Windows să-i spună VFP să închidă Class Designer în acel moment - să nu aștepte până mai târziu, când va lua o respirație.

Lista 15.1 Cod necesar pentru a subclasa programul proiecthook

LPARAMETERS tcProjectHook, tcProjectFieldMappingConfig

#define ccPROJECTHOOKSLIB "k:\vfpaddon\rasprojecthooks\cProjectHooks"

#define ccPROJECTHOOKSBASELIB "k:\vfpaddon\rasprojecthooks\cPhkBase"

#define ccPROJECTHOOKSBASE „phkDevelopment”

creați clasa (tcProjectHook) de ccPROJECTHOOKSLIB ;

ca ccPROJECTHOOKSBASE din ccPROJECTHOOKSBASELIB nowait

* 	Setați proprietatea clasei pentru proprietatea projecthook cFieldMappingCategory

aselobj(laProjectHookRef, 1)

if type("laProjectHookRef[1]") = "O"

laProjectHookRef[1].cFieldMappingCategory = tcProjectFieldMappingConfig

endif

* 	Asigurați-vă că referința la projecthook este eliberată lansarea laProjectHookRef

* 	Gestionați Windows VFP care se deschid fără fișier de resurse

daca wexist("PROPRIETATI")

eliberați fereastra „Proprietăți”

endif

if wexist("CONTROLE FORMELOR")

eliberați fereastra „FORM CONTROLS”

endif

* 	Închideți clasa nou creată deschisă în Class Designer

* 	Apăsările de taste sunt „bufferizate” până când toate clasele sunt create tastatura „{CTRL+W}”

* 	Adăugat pentru a închide designerii de clasă în jos doevents()

Pașii unsprezece și doisprezece sunt calitățile de lucru atunci când vine vorba de a utiliza obiectul proiect și obiectul fișier. Aici este creat, populat și construit inițial proiectul aplicației. Ca de obicei, există câteva aspecte cheie de subliniat.

Mai întâi sunt câteva „funcții” sau proprietăți lipsă din obiectul proiectului. Acestea sunt articolele autorului, cum ar fi numele, compania și adresa. Sperăm că acestea vor apărea în următoarea versiune a VFP. Ar fi bine să prepopulați aceste setări în proiect atunci când îl creați.

Metoda Files obiect Add efectuează toată magia. Cheia acestei metode este să vă asigurați că includeți extensia fișierului pe care îl adăugați. Acesta este modul în care VFP înțelege în ce categorie de fișiere să-l adauge în Managerul de proiect. Primul element major este de a crea proiectul prin comanda CREATE PROJECT. Rețineți că proiectul este creat cu opțiunea NOPROJECTHOOK. Acest lucru asigură că niciun cârlig nu este asociat cu proiectul până când nu este adăugat ulterior. Ea anulează chiar și o setare globală de cârlig. Apoi adăugați toate fișierele necesare. Am descoperit că aveți nevoie de cel puțin un fișier din fiecare director pentru fiecare tip de fișier. De exemplu, dacă avem biblioteci de clase în directorul Libs al proiectului și directorul Libs al cadrului, trebuie să adăugăm câte un fișier din fiecare. În acest fel construirea proiectului

poate găsi restul fișierelor în calea de căutare pe care o stabilește din fișierele adăugate anterior. Orice fișier apelat prin tehnica apelurilor indirecte (prin substituție de macro sau evalo) trebuie, de asemenea, adăugat cu apeluri directe la metoda Add.

Codul din Lista 15.2 este doar o mică parte a codului pe care îl folosim în producție. Dacă sunteți interesat să citiți întregul program, acesta este disponibil în fișierele de descărcare pentru dezvoltatori disponibile la www.hentzenwerke.com ca GenProjectFile.prg cu celelalte exemple din acest capitol.

Listing 15.2 Cod folosit pentru a genera proiectul, a-l popula cu fișiere și inițial a construi proiectul pentru a extrage fișierele asociate

LPARAMETERS tcProjPrefix, tcProjectDir, ;

tcBusinessGroupDir, tcSystem, tcProj ectHook

#DEFINE ccPROJECTHOOKSLIB "k:\vfpaddon\rasprojecthooks\cProjectHooks.vcx"

CREATE PROJECT (lcProjectName) ACUM Așteptați SALVARE NOSHOW NOPROJECTHOOK

IF TYPE("_vfp.ActiveProject") = "O" AND !ISNULL(_vfp.ActiveProject);

AND FILE(lcProjectName)

? „Fișierul proiect creat „ + lcProjectName + „ la „ + TTOC(DATETIME())

CU _vfp.ActiveProject

* 	Setați unele dintre informațiile Versiunii de compilare

.HomeDir = tcProjectDir

.AutoIncrement = .T.

.Depanare = .T.

.VersionNumber = „1.0.0”

.VersionComments = „Aplicație Visual FoxPro”

.VersionCompany = „Kirtland Associates, Inc”

.VersionDescription = ""

.VersionCopyright = ALLTRIM (STR(YEAR(DATE())) )

.VersionTrademarks = ""

.VersionProduct = ALLTRIM(tcSystem)

.VersionLanguage = „Engleză”

* 	RAS 05-oct-1999 A fost adăugată conexiunea projecthook.

* 	Trebuie să fie în această ordine, prima bibliotecă, clasa a doua

* 	în caz contrar, este afișat un dialog și expertul se blochează

.ProjectHookLibrary = ccPROJECTHOOKSLIB

.ProjectHookClass = ALLTRIM(tcProjectHook)

* 	Programul principal trebuie adăugat mai întâi pentru a deveni

* 	SET MAIN pentru proiect

lcFile = tcProjectDir + „programs\” + tcProjPrefix + „Main.prg”

Efectuați AddFileToProject CU lcFile

* 	Adăugați containerul bazei de date

lcFile = tcProjectDir + lcDatabaseDir + tcProjPrefix + „.dbc”

Efectuați AddFileToProject CU lcFile

* 	Adăugați câteva mese gratuite

lcFile = tcProjectDir + „system\” + tcProjPrefix + „config.dbf”

Efectuați AddFileToProject CU lcFile

* Adăugați clasele Stonefield Database Toolkit

lcFile = "K:\VfpAddOn\Stonefield\SDT\Source\DbcxMgr.vcx"

Efectuați AddFileToProject CU lcFile

lcFile = "K:\VfpAddOn\Stonefield\SDT\Source\SDT.vcx"

Efectuați AddFileToProject CU lcFile

* 	RAS 27-Sep-1999 A fost adăugat șablonul Config.fpw

lcFile = tcProjectDir + „text\” + „Config.fpw”

Efectuați AddFileToProject CU lcFile

* 	Asigurați-vă că fișierul de configurare este inclus

_vfp.ActiveProject.Files("Config.fpw").Exclude = .F.

* 	RAS 27-Sep-1999 A fost adăugat șablonul ReadMe.txt

lcFile = tcProjectDir + „text\” + „ReadMe.txt”

Efectuați AddFileToProject CU lcFile

* 	Asigurați-vă că fișierul de configurare este inclus

_vfp.ActiveProject.Files(„ReadMe.txt”).Exclude = .T.

* 	Construiți proiectul folosind opțiunea Rebuild pentru a intra

* 	restul fișierelor de proiect

llBuildResult = .Build(1)

? "Rezultatul de la compilare a fost: " + TRANSFORM(llBuildResult) + ;

" la " + TTOC(DATETIME())

SE TERMINA CU

ALTE

? „Crearea fișierului de proiect a eșuat pentru „ + lcProjectName + ;

" la " + ttoc(datatime())

ENDIF

PROCEDURĂ AddFileToProject (tcFileName)

IF FILE(tcFileName)

_vfp.ActiveProject.Files.Add(tcFileName)

? „Fișier adăugat: „ + tcFileName + „ la „ + TTOC(DATETIME())

ALTE

? " Problemă la adăugarea fișierului " + tcFileName

ENDIF

ÎNTOARCERE

*: EOF :*

Metoda de construcție a obiectului de proiect vă permite să faceți oricare dintre opțiunile de construcție disponibile dezvoltatorului prin intermediul casetei de dialog Opțiuni de construcție a proiectului. Am ales proiectul de reconstrucție, astfel încât restul fișierelor de proiect să fie extrase după cum este necesar și fiecare fișier este compilat pentru prima dată.

În general, acest proiect a fost distractiv și a demonstrat puterea de a avea o interfață deschisă pentru mediul de dezvoltare. De asemenea, ne economisește timp și bani pentru fiecare proiect la care lucrăm.
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Trucuri ProjectHook și Project Object

Vom folosi un projecthook din viața reală, în producție, care a fost folosit de autor de la sfârșitul versiunii beta VFP 6.0. Vom demonstra, de asemenea, cum proiectul și obiectul proiect pot fi utilizate împreună cu un nou instrument numit RAS Project Builder.
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Cum să îmbunătățiți proiectul de bază

Există mai multe fișiere care alcătuiesc biblioteca de clase CPhkBase. Prima este clasa phkBase. Această clasă este o subclasă directă a proiecthook-ului VFP. Este întotdeauna o practică bună să vă construiți propria copie a claselor VFP, astfel încât să aveți o bază pentru îmbunătățiri la un nivel al ierarhiei claselor. Toate celelalte clase sunt subclasate din clasa phkBase (vezi Figura 15.3). Am adăugat câteva metode și proprietăți la acest nivel despre care știam că vor fi la îndemână pentru toate proiectele pe care le-am dezvoltat (vezi

Tabelul 15.2 și Tabelul 15.3)

Tabelul 15.2 Metode adăugate la proiectul nostru phkBase cu o scurtă descriere a utilizării lor

Descrierea metodei	
DeveloperMessage 	Folosit pentru a afișa un mesaj dezvoltatorului. Dacă IWaitMessage este adevărat, se afișează WAIT WINDOW, în caz contrar mesajul este trimis în fereastra DEBUGOUT.
GetPProp 	Returnează valoarea proprietății trimise ca parametru. Acest lucru permite dezvoltatorilor să acceseze proprietăți protejate cu o interfață simplă.
Eliberare 	Eliberează obiectul instanțiat.
SetProjectObjReferen ce 	Folosit pentru a configura proprietatea ProjectInfo la ActiveProject, dacă există. Da, există posibilitatea ca un dezvoltator să instanțieze un proiect hook fără un proiect.
ShellA dditionalInit 	Folosit pentru a extinde metoda Init() fără a fi nevoie să suprascrieți codul Init() în subclase. Apelat din metoda Init().
zzAbout 	Conține orice documentație specifică clasei.

Tabelul 15.3 Proprietăți adăugate la proiectul nostru phkBase cu o scurtă descriere a utilizării lor

Descriere proprietăți	
Builder 	Programul (prg) sau biblioteca/clasa vizuală (vcx) care indică generatorul pentru clasa bazată în BUILDER.DBF.
BuilderX 	Clasa vizuală care indică BuilderB Builder pentru această clasă.
cVersion 	Numărul de versiune al clasei specifice.
IWaitMessage 	Comută mesajele între instrucțiunile WAIT WINDOWS sau DEBUGOUT în modul dezvoltator.
oProjectInfo 	Conține o referință la obiect la informațiile despre proiect.

Proprietățile Builder și BuilderX sunt proprietăți pe care constructorii VFP nativi le vor recunoaște. Aceste cârlige vor fi la îndemână dacă creați o clasă/program de constructor de proiecthook.

Există alte două clase de proiecthook în bibliotecă. Primul este phkTestPems. Scopul acestei clase în viață a fost să testeze proprietățile, evenimentele și metodele oferite de VFP. Am folosit această clasă ca parte a ciclului beta pentru a verifica că primim ceea ce reclamă Microsoft. Nu există metode sau proprietăți suplimentare. Există un cod în fiecare dintre metodele de evenimente VFP care declanșează un mesaj folosind următorul cod:

ACEST. DeveloperMessage (PROGRAM ( ) )

Proprietatea IWaitMessage este setată la true, astfel încât atunci când rulați acest cod, obțineți o fereastră de așteptare de fiecare dată când este declanșat un cârlig când se efectuează o acțiune de la Managerul de proiect. Nu este chiar util, dar își servește scopul de a testa diferitele evenimente.

Figura 15.3 Bibliotecă de clase CPhkBase care arată ierarhia claselor pentru proiectele
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Cum să creați un proiect de dezvoltare util

Ultima clasă, phkDevelopment, este carnea și cartofii adevărati ai bibliotecii. Aceasta este baza pentru toate proiectele specifice proiectului. Această clasă oferă unele funcționalități cheie pe care mulți dezvoltatori VFP au dorit să fie adăugate la IDE-ul nativ. Aceasta este adevărata frumusețe a extensiei projecthook. Ne permite să adăugăm funcționalități mediului de dezvoltare fără a fi nevoie să așteptăm ca Microsoft să ne mute cererea în partea de sus a listei de priorități. Acest concept de îmbunătățire a dezvoltării face ca VFP să strălucească față de alte instrumente de dezvoltare. Unele dintre caracteristicile pe care le-am implementat în phkDevelopment:

• 	Utilitar de cartografiere a câmpurilor

• 	Curăţarea informaţiilor codificate de imprimantă din rapoarte

• 	Audit de proiect (urmărirea activității)

• 	Capacitate de copiere a fișierelor

• 	Afișarea mesajelor compilatorului/build-ului în bara de stare sau WAIT WINDOW

• 	Instanțierea barei de instrumente cu butonul pentru a apela RAS Project Builder

• 	Schimbarea directorului implicit în directorul proiectului

• 	Ajustarea căii personalizate la o cale de proiect

Fiecare dintre aceste caracteristici majore va fi discutată în secțiunile următoare.

Tabelul 15.4 Metode adăugate la proiectul nostru de dezvoltare cu o scurtă descriere a utilizării lor

Descrierea metodei	
cBuildMessageSetting_assign 	Certifică faptul că au fost făcute atribuirile corespunzătoare ale proprietății cBuildMessageSetting.
cCleanReportPninters_assign 	Certifică faptul că sunt făcute atribuirile corespunzătoare ale proprietății cCleanReportPrinters.
ChangeToProjectDirectory 	Schimbă directorul implicit în directorul principal al proiectului.
ChangeToProjectPath 	Adaugă directoare la SET PATH care sunt necesare pentru proiect.
CleanReportPrn ter 	Va elimina informațiile codificate de imprimantă din fișierul de metadate Raport (.FRX).
	

FieldMappingDo 	Apelat pentru a procesa toate Verificările Field Mapping, apoi rulează procesul.
FieldMappingPropertyCheck 	Folosit pentru a verifica toate setările dezvoltatorului pentru proprietățile Field Mapping ale acestui ProjectHook.
FieldMappingSet 	Folosit pentru a seta setările Field Mapping la registry.
FieldMappingTableClose 	Folosit pentru a închide tabelul de opțiuni de mapare a câmpurilor.
FieldMappingTableOpen 	Folosit pentru a deschide tabelul de opțiuni de mapare a câmpurilor.
ModifyFileBackup 	Folosit pentru a crea un fișier de tip .bak al fișierelor de cod sursă care nu au acest comportament nativ.
ProcessReportFiles 	Apelat din metoda Build pentru a parcurge fișierele și a procesa orice rapoarte necesare înainte de a construi.
ProjectActivate 	Declanșat de metoda claselor Init() pentru a procesa articole atunci când proiectul este deschis sau activat.
ProjectAuditDo 	Apelat pentru a face verificările corespunzătoare, apoi apelează deschiderea tabelului de audit al proiectului.
ProjectAuditSetSessionId 	Inițializează proprietatea cSessionId pentru capacitatea de audit al proiectului.
ProjectA uditTableClose 	Folosit pentru a închide tabelul Project Audit.
ProjectAuditTableCreate 	Folosit pentru a genera tabelul folosit de funcționalitatea de audit al proiectului.
	

ProjectA uditTableOpen 	Folosit pentru a deschide tabelul de audit al proiectului.
ProjectA uditTableReindex 	Folosit pentru a reconstrui indecșii pentru tabelul de audit al proiectului.
ProjectAuditUpdate 	Actualizează tabelul de audit al proiectului.
ProjectBuilderToolBarinit 	Instanțiază bara de instrumente RAS Project Builder dacă este primul proiect deschis și proprietatea lUseProjectBuilderTb este setată la true.
ProjectB uilderToolBarinit 	Lansează bara de instrumente RAS Project Builder dacă este ultimul proiect în picioare și bara de instrumente există.

Tabelul 15.5 Proprietăți adăugate la proiectul nostru de dezvoltare cu o scurtă descriere a utilizării lor

Descriere proprietăți	
aErrorDetail[1,0] 	O colecție de detalii despre ultima eroare care a apărut în timpul procesării.
cBuildMessageSetting 	Conține tipul de setare a mesajului, bara de stare „S” (implicit) și fereastra de așteptare „W”.
cCaption 	Conține legenda pentru MessageBox().
cCleanReportPrin ters 	Conține indicatorul dacă rapoartele din proiect ar trebui să aibă informațiile despre imprimantă eliminate din metadate (.FRX). Setările includ „C”lean, „Vizualizare” sau „S”kip (implicit).
cDeveloper	

	Este folosit ca identificator pentru proiecthook. Acesta este pentru uz intern de către rutina RAS Project Builder.
cFieldMappingCategory 	Este utilizat pentru a seta tipurile de date de mapare a câmpurilor la setările pentru această categorie din tabelul de opțiuni de mapare a câmpurilor.
cFieldMappingTableAlias 	Conține ALIAS() utilizat pentru tabelul de opțiuni de mapare a câmpurilor.
cFieldMapping TableDirectory 	Conține directorul către Field Mapping Table.
cFieldMappingTableName 	Conține numele tabelului tabelului de opțiuni de mapare a câmpurilor.
cFieldMapping VfpCategory 	Conține categoria implicită pentru a seta toate tipurile de date de mapare a câmpurilor la clase de bază VFP.
cOldNotify 	Conține vechiul SET('NOTIFY') pentru resetare ulterioară.
ColdStatusBar 	Conține vechiul SET('STATUS BAR') pentru resetare ulterioară.
cOldTalk 	Conține vechiul SET('TALK') pentru resetare ulterioară.
cOldTalkWin 	Conține vechiul SET('TALK,1') pentru resetare ulterioară.
cPathDirectories 	Conține directoarele suplimentare care trebuie să fie în SET PATH.
cPathDirectories 	Conține directoarele suplimentare care trebuie să fie în SET PATH.
	

cProjectA uditAlias 	Conține aliasul tabelului de audit al proiectului setat la deschiderea tabelului.
cProjectA uditDirectory 	Conține calea directorului pentru Tabelul de audit al proiectului.
cProjectA uditTable 	Conține numele tabelului folosit pentru a urmări evenimentele proiectului.
cProjectBuilderGlobalVariable 	Este numele variabilei sub care este instanțiată bara de instrumente Project Builder.
cProjectB uilderTbClass 	Conține numele clasei care este bara de instrumente RAS Project Builder.
cProjectB uilderTbClassLib 	Deține numele bibliotecii de clase în care se află bara de instrumente RAS Project Builder.
cSessionId 	Conține id-ul unic de sesiune pentru proiect. Acesta este stocat în tabelul de audit al proiectului pentru a determina toate evenimentele care au avut loc într-o sesiune.
lCrea teBackupFile 	Când codul sursă este modificat, determină dacă este creat fișierul de tip .bak care nu are acest comportament nativ.
lFieldMappingActive 	Este folosit pentru a avea caracteristica Field Mapping activă pentru ProjectHook.
lUseProjectA udit 	Determină dacă capabilitățile de audit de proiect sunt utilizate pentru acest proiect curent.
lUseProjectB uilderTb 	Determină dacă bara de instrumente RAS Project Builder este instanțiată atunci când această clasă este instanțiată.
oRegistry 	Această proprietate conține o referință la obiectul Registry Manipulation.
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Cum să setați proiecthook directorul curent și calea

Înainte de proiecthook, de fiecare dată când deschideam un nou proiect, eram forțați să schimbăm manual directorul VFP implicit în directorul proiectului. Acest lucru se face astfel încât formularele individuale să poată fi rulate autonom, iar SET PATH găsește corect toate fișierele necesare pentru a rula caracteristicile pe care le dezvoltăm. De obicei, autorul atinge o jumătate de duzină de proiecte în fiecare zi și acest lucru poate deveni destul de obositor.

Mulți dezvoltatori au creat un program pentru a seta calea, directorul curent și alte setări de mediu înainte de a deschide proiectul cu MODIFY PROJECT ..NOWAIT. Acest lucru nu mai este necesar, deoarece projecthook poate rula același tip de cod de fiecare dată când proiectul este deschis. Deci, care sunt avantajele dintre un program care face acest lucru și instanțierea projecthook? Există o serie de avantaje. În primul rând, nu avem nevoie de un program personalizat duplicat pentru fiecare proiect, deoarece codul este scris o dată în clasa projecthook de cel mai înalt nivel. Întreținerea este redusă la minimum prin proiectarea orientată pe obiecte a clasei. În continuare, nu există căi de codificare hard în program. Projecthook folosește directorul de proiect care este deja stocat în proiect. În al treilea rând, pot folosi IDE-ul VFP pentru a deschide proiecte și nu-mi face griji că întreaga listă de programe de deschidere a proiectelor se află în calea VFP existentă și mă asigur că deschidem proiectul corect. Aceasta este o problemă, deoarece majoritatea dezvoltatorilor numesc programul de deschidere a proiectului în mod identic pentru toate proiectele. Deci în ce director suntem? Ce proiect se va deschide când rulez SetPath.prg? Cu projecthook-ul desemnat pentru proiect, doar apăsăm pe meniul Fișier și alegem unul dintre ultimele proiecte la care am lucrat sau sărim la fereastra de comandă și executăm linia de cod MODIFY PROJECT care este deja acolo. Simplu.

Deci, ce cod este necesar pentru a avea acest avantaj? Iată două metode extrase din clasa phkDevelopment care sunt apelate din metoda ProjectActivate:

* 	phkDevelopment.ChangeToProj ectDirectory()

* 	Setați directorul implicit în casa proiectului

* 	director, astfel încât calea generică să funcționeze

* 	adică SETĂ CALEA LA date, formulare, clase, grafice

IF TYPE("THIS.oProjectInfo") = "O" AND !ISNULL(THIS.oProjectInfo)

IF !EMPTY(THIS.oProjectInfo.HomeDir)

CD (THIS.oProjectInfo.HomeDir)

ALTE

THIS.DeveloperMessage(„Setarea directorului de proiect este goală...”, .T.)

ENDIF

ALTE

* 	Acest lucru nu ar trebui să se întâmple niciodată, cu excepția cazului în care faci manual

* 	CREATEOBJECT() clasa fără proiect.

THIS.DeveloperMessage(„Referința proiectului nu este disponibilă”, .T.)

ENDIF

* 	PhkDevelopment.ChangeToProjectPath()

LOCAL lcOldPath && Păstrați vechiul SET PATH

DACĂ !ISNUH(THIS.cPathDirectories) ȘI !EMPTY(THIS.cPathDirectories)

IF VARTYPE(THIS.cPathDirectories) = „C”

lcOldPath = SET(„CALEA”)

lcNewPath = THIS.cPathDirectories

SETĂ CALEA LA &lcOldPath, &lcNewPath

EISE

THIS.DeveloperMessage(„Proprietatea directorului de căi nu este caracter”)

ENDIF

EISE

* Nu există cerințe speciale de traseu pentru acest proiect

ENDIF

Există un dezavantaj al acestei metode. Deoarece nu există o metodă Activare pentru proiect la care să ne putem conecta, acest cod este rulat doar când deschidem proiectul. Instrumentul RAS Project Builder discutat mai târziu în acest capitol are o soluție pentru această problemă.
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Cum să controlați programatic setările VFP IntelliDrop

Visual FoxPro 5.0 a introdus caracteristica IntelliDrop nativă pentru mediul de dezvoltare. Când construiți formulare și clase, puteți glisa și plasa elemente din mediul de date, un proiect sau Database Designer, iar când le plasați în designer, clasa specificată este utilizată la crearea obiectului. Marele avantaj al acestui lucru este că puteți specifica clasele în loc să utilizați clasele de bază VFP implicite. Capacitatea IntelliDrop este gestionată prin intermediul casetei de dialog Tool|Options din pagina Field Mapping. Aceste setări sunt păstrate în Registrul Windows. Vedeți imediat beneficiile acestei funcționalități. Este încă o modalitate de a personaliza mediul de dezvoltare.

Există două mari dezavantaje ale acestei implementări. Primul este unul care se realizează imediat dacă utilizați diferite clase în diferite proiecte. Acest lucru s-ar putea datora faptului că aveți clase de cadre subclasate pentru fiecare proiect sau s-ar putea ca clienți diferiți să aibă cod sursă din cadre diferite.

Al doilea este faptul că aceste setări sunt stocate în registry, care este specific mașinii. Dacă aveți mai mulți dezvoltatori care lucrează la același proiect, fiecare trebuie să treacă prin procesul plictisitor de setare a setărilor Field Mapping pentru proiect. Acest lucru este complicat de faptul că majoritatea dezvoltatorilor lucrează la mai multe proiecte. Dacă aveți probleme cu o mașină și doriți să treceți la o altă mașină din rețea, trebuie să parcurgeți și să resetați acele setări pentru acea mașină.

Acest lucru poate fi mai mult decât o agravare. Din fericire, există o soluție care poate fi dezvoltată cu un program sau un projecthook. Gurul VFP John Petersen a împărtășit un instrument pe care l-a dezvoltat, numit OptUtility. Aceasta este o combinație simplă de formular și tabel care stochează diferite configurații pentru toate clasele de bază VFP. Efectuează toate operațiunile de întreținere și scrie direct în și din registru pentru a mapa aceste setări. Rulați formularul, selectați gruparea de proiecte și apăsați un buton pentru a actualiza registrul. Acesta este un instrument grozav pe care îl folosesc tot timpul. Singura problemă este că trebuie să-mi amintesc să merg să apăs butonul. Ocazional, acest lucru este trecut cu vederea și obțin polenizarea încrucișată a bibliotecilor de clasă în diferitele mele proiecte.

Tabelul 15.6 Tabel liber OptUtil.dbf care stochează informațiile de mapare a câmpurilor utilizate în porțiunea IntelliDrop Manager a hook-ului de proiect phkDevelopment

Câmp 	NameTypeSizeDescription
1 	ConfigC20, 0Acesta este numele configurației. Completem acest lucru cu o referință care este legată pentru a reprezenta proiectul.
2 	TypeC20, 0Acesta este numele obiectului clasei de bază VFP.
3 	ClassNameC50, 0	

Acesta este numele clasei care este setat în registru pentru clasa de bază VFP în

secțiunea Maparea câmpurilor.

4

ClassLoc C

254, 0

Aceasta este biblioteca de clase (cu fullpath) în care se află clasa desemnată în coloana ClassName.

Prima dată când am văzut VFP 6.0 și projecthooks, am văzut imediat utilizarea projecthook-ului pentru a actualiza registry cu informațiile mapate în tabelul OptUtility. Deoarece projecthook-ul este instanțiat atunci când proiectul este deschis, am putea să ne conectăm la procesul de inițializare și să rulăm cod pentru a mapa clasele la registry. Codul pentru aceasta se găsește în Lista 15.3. Acest lucru a eliminat necesitatea de a vă aminti să rulați OptUtility de fiecare dată. Dezavantajul acestui lucru este că nu există nicio metodă de activare a proiectului disponibilă, așa că dacă săriți proiecte sau deschideți un alt proiect, veți obține noua mapare și veți avea aceleași probleme potențiale ca și dacă uitați să rulați utilitarul de mapare.

Lista 15.3 Acest cod se găsește în metoda FieldMappingSet a programului de proiect phkDevelopment. Acest cod mapează setările IntelliDrop la Registrul Windows pe baza grupării selectate.

* 	Rădăcini de registry (smulse din VFP98\ffc\Registry.h)

#DEFINE HKEY_CLASSES_ROOT -2147483648 && BITSET(0,31)

#DEFINE HKEY_CURRENT_USER -2147483647 && BITSET(0,31)+1

#DEFINE HKEY_LOCAL_MACHINE -2147483646 && BITSET(0,31)+2

#DEFINE HKEY_USERS -2147483645 && BITSET(0,31)+3

LOCAL lcIntellidropKey && Cheie de opțiuni de registru VFP pentru Intellidrop

LOCAL lnOldSelect && Salvați vechea zonă de lucru

* 	Procesați intrările din registry numai dacă obiectul Registry este instanțiat

IF !ISNULL(THIS.oRegistry)

* 	Construiți prima parte a cheii de registry pentru Intellidrop

lcIntellidropKey = "Software\Microsoft\VisualFoxPro\" + ;

_VFP.VERSIUNE +;

„\Opțiuni\Intellidrop\FieldTypes\”

lnOldSelect = SELECT ()

lcFieldMapAlias = THIS.cFieldMappingTableAlias

* 	Obțineți toate setările de clasă pentru proiect

SELECTAȚI * ;

FROM (lcFieldMapAlias) ;

WHERE Config = ALLTRIM(THIS.cFieldMappingCategory) ;

INTO CURSOR curSetReg

lnRecords = _TALLY

DACĂ _TALLY = 0

THIS.DeveloperMessage("Nici o clasă de mapare a câmpurilor nu înregistrează la " + ;

proces pentru " + ;

ALLTRIM(THIS.cFieldMappingCategory))

ALTE

* 	Actualizați Registrul

SCANĂ

* 	Aceasta este setarea Visual Class Library

THIS.oRegistry.SetRegKey(„Locație clasa”, ;

ALLTRIM(curSetReg.ClassLoc),;

lcIntellidropKey + ALLTRIM(curSetReg.Type),;

HKEY_CURRENT_USER)

* 	Acesta este clasa reală stabilită pentru clasa de bază

THIS.oRegistry.SetRegKey(„ClassName”, ALLTRIM(curSetReg.ClassName),;

lcIntellidropKey + ALLTRIM(curSetReg.Type),;

HKEY_CURRENT_USER)

THIS.DeveloperMessage(ALLTRIM(curSetReg.Type) + ;

" setat la " + ;

ALLTRIM(curSetReg.ClassLoc) + "::" + ;

ALLTRIM(curSetReg.ClassName), ;

.T.)

ENDSCAN

ENDIF

* 	Închideți cursorul de temperatură

UTILIZARE ÎN curSetReg

SELECTARE (lnOldSelect)

ALTE

THIS.DeveloperMessage(„Obiectul registry nu este instanțiat”)

ENDIF

* 	În cazul în care mesajele sunt trimise în FEREASTRA DE AȘTEPTARE

Așteptați clar

Sincer, această caracteristică poate economisi o cantitate enormă de timp dacă schimbați în mod constant proiecte, așa cum facem noi. Dacă lucrați la același proiect tot timpul sau utilizați doar un set de clase de bază pentru toate proiectele dvs., această parte a proiectului hook va fi aproape inutilă. Puteți dezactiva această funcție setând proprietatea IFieldMappingActive la .f..
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Cum să eliminați informațiile despre imprimantă din rapoartele VFP

Au existat o mulțime de scrieri în diferitele forumuri online și publicații FoxPro despre metadatele raportului care păstrează informații despre imprimantele de dezvoltare. Acest lucru poate cauza o serie de probleme de asistență într-o aplicație de producție dacă clientul nu are aceleași imprimante.

Au existat mai multe soluții pentru dezvoltatori la această problemă. Cele mai multe sunt scrise ca un program care scanează fișierul de proiect (.pjx), deschide metadatele raportului și apoi șterge coloanele Tag și Tag2 din prima înregistrare. Steve Sawyer a transmis unul dintre cele mai bune programe care realizează acest serviciu. Am încorporat acest cod, împreună cu îmbunătățirile lui Steve, pentru a modifica selectiv anumite informații din coloana Expr a primei înregistrări din metadatele raportului.

Codul pentru a efectua curățarea este localizat în metoda CleanReportPrinter din projecthook, care este apelată de ProcessReportFiles. Codul CleanReportPrinter curăță specificul imprimantei într-un fișier de raport. Ca și în cazul tuturor funcțiilor phkDevelopment, funcția poate fi activată și dezactivată. Acest lucru se realizează cu proprietatea cCleanReportPrinters. Există mai multe setări disponibile. „Clean” va face ca scruberul să facă treaba, „View” va efectua mesajele WAIT WINDOW dacă logica altfel nu este comentată (până când se realizează o implementare mai bună), iar „Skip” va ocoli procesul în totalitate.

Lista 15.4 Acest cod se găsește în metoda CleanReportPrinter a programului de proiect phkDevelopment. Acest cod golește câmpurile Tag și Tag2 ale primei înregistrări din fișierul de metadate ale raportului. Detaliile selective ale coloanei Expr din prima înregistrare sunt, de asemenea, eliminate.

* 	Rapoartele au un obicei urât de a salva informațiile despre imprimantă în

* 	prima înregistrare a metadatelor raportului. Această rutină în mod selectiv

* 	elimină unele dintre informațiile de imprimantă hardcoded astfel încât utilizatorii

* 	poate folosi fără probleme imprimante diferite decât personalul de dezvoltare.

LPARAMETERS tcFrx2Chk, tcAction

*? Mai trebuie să vină cu o alternativă la Vizualizați informațiile raportului

* 	Verificarea parametrilor

IF VARTYPE(tcAction) != „C” SAU EMPTY(tcAction)

This.DeveloperMessage(„Parametrul raportului a fost gol de tipul de date incorect”)

ÎNTOARCERE

ENDIF

IF VARTYPE(tcAction) != „C”

tcAction = "VIZUALIZARE"

ENDIF

* 	Treceți la afacerea metodei

This.DeveloperMessage(PROPER(tcAction) + "ing Report: " + tcFrx2Chk, .T.)

* 	Verificați dacă raportul există

IF FILE(tcFrx2Chk)

UTILIZAȚI (tcFrx2Chk) ALIAS curFrx2Chk EXCLUSIV

ALTE

This.DeveloperMessage(tcFrx2Chk + " nu există.")

ÎNTOARCERE

ENDIF

* 	Verificați dacă raportul a fost deschis în regulă (în caz contrar, gestionarea erorilor doar

* 	a afișat un mesaj și viața a continuat).

DACĂ !FOLOSIT("curFrx2Chk")

ÎNTOARCERE

ENDIF

LOCALIZA

* 	Gestionați câmpul Expresie

IF !EMPTY(curFrx2Chk.Expr)

IF UPPER(tcAction) == „CURAT”

ÎNLOCUIȚI curFrx2Chk.Expr CU ;

STRTRAN(curFrx2Chk.Expr, [DEVICE], [*DEVICE])

ÎNLOCUIȚI curFrx2Chk.Expr CU ;

STRTRAN(curFrx2Chk.Expr, [DRIVER], [*DRIVER])

ÎNLOCUIȚI curFrx2Chk.Expr CU ;

STRTRAN(curFrx2Chk.Expr, [IEȘIRE], [*IEȘIRE])

ÎNLOCUIȚI curFrx2Chk.Expr CU ;

STRTRAN(curFrx2Chk.Expr, [DEFAULT], [*DEFAULT])

ÎNLOCUIȚI curFrx2Chk.Expr CU ;

STRTRAN(curFrx2Chk.Expr, [PRINTQUALITY], [*PRINTQUALITY])

ÎNLOCUIȚI curFrx2Chk.Expr CU ;

STRTRAN(curFrx2Chk.Expr, [YRESOLUTION], [*YRESOLUTION])

ÎNLOCUIȚI curFrx2Chk.Expr CU ;

STRTRAN(curFrx2Chk.Expr, [TTOPTION], [*TTOPTION])

ÎNLOCUIȚI curFrx2Chk.Expr CU ;

STRTRAN(curFrx2Chk.Expr, [DUPLEX], [*DUPLEX])

This.DeveloperMessage(tcFrx2Chk + „coloana Expr: curățat”, .T.)

ALTE

* 	This.DeveloperMessage(tcFrx2Chk + " coloana Expr: " + curFrx2Chk.Expr)

ENDIF

ENDIF

* 	Gestionați câmpul Etichetă

IF !EMPTY(curFrx2Chk.TAG)

IF UPPER(tcAction) == „CURAT”

ÎNLOCUIȚI curFrx2Chk.TAG CU SPAȚIU(0)

This.DeveloperMessage(tcFrx2Chk + „ coloană Tag: cleaned”, .T.)

ALTE

* 	This.DeveloperMessage(tcFrx2Chk + " coloana Tag: " + curFrx2Chk.Tag)

ENDIF

ENDIF

* 	Gestionați câmpul Tag2

IF !EMPTY(curFrx2Chk.Tag2)

IF UPPER(tcAction) == „CURAT”

ÎNLOCUIȚI curFrx2Chk.Tag2 CU SPAȚIU(0)

This.DeveloperMessage(tcFrx2Chk + „coloana Tag2: cleaned”, .T.)

ALTE

* 	This.DeveloperMessage(tcFrx2Chk + " coloana Tag2: " + curFrx2Chk.Tag2)

ENDIF

ENDIF

* 	Acum împachetați pentru a vă asigura că nu vă umflați cu notele

IF UPPER(tcAction) = „CURAT”

AMBALAJ

ENDIF

* 	Închideți raportul (.frx)

DACĂ FOLOSIT([curFrx2Chk])

UTILIZAȚI ÎN curFrx2Chk

ENDIF

Așteptați clar

ÎNTOARCERE

Această rutină este apelată din RAS Project Builder, care este discutat mai târziu în acest capitol. Nu vă recomandăm să rulați acest lucru pentru fiecare build, deoarece nu este necesar în mediul de dezvoltare decât dacă imprimați pe mai multe imprimante din birou. Este posibil ca această teorie să nu se aplice dacă raportul a fost dezvoltat cu o imprimantă care diferă de imprimanta implicită a Windows. Pe de altă parte, este foarte recomandat să efectuați această rutină în ciclul de producție înainte de a o trimite la un site client.
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Cum să urmăriți ceea ce se face în cadrul managerului de proiect

Te-ai întrebat vreodată de câte ori ai modificat un anumit fișier sau cine a fost ultima persoană care a atins biblioteca de clasă critică? Există o mulțime de opțiuni când vine vorba de Controlul sursei care vă vor oferi aceste statistici. VFP lucrează cu furnizori de control sursă care se conformează interfeței de programare a aplicației de control sursă (API). Dar dacă nu aveți aceste controale implementate în biroul dvs.? Ce se întâmplă dacă ai vrea să știi de câte ori ai deschis un proiect sau ai construit codul? Ce poti face? O opțiune este să implementezi ceea ce eu numesc „pistul de audit al proiectului al dezvoltatorului sărac”.

Există o serie de metode care se execută atunci când sunt declanșate evenimente Manager de proiect. Fiecare dintre aceste metode de eveniment are un apel la metoda ProjectAuditUpdate. Iată codul din metoda QueryModifyFile a projecthook:

THIS.ProjectAuditUpdate(„Fișier modificat”, laFișier.Nume + ;

IIF(EMPTY(tcClassName),"","(" + tcClassName + ")"))

Este important să rețineți că, dacă această caracteristică nu este dorită (ca și cum ar fi <g>), puteți comuta proprietatea lUseProjectAudit la .f..

Lista 15.5 Acest cod se găsește în metoda ProjectAuditUpdate a hook-ului de proiect phkDevelopment și inserează un rând într-un tabel liber VFP specificat de proprietatea cProjectAuditTable

LPARAMETER tcActivity, tcParameter

DACĂ ASTA.lUseProjectAudit

DACA PCOUNT() < 2 SAU VARTYPE(tcParameter) != "C"

tcParameter = ""

ENDIF

* 	Verificați întotdeauna pentru a vedea dacă masa este deschisă din cauza posibilității

* 	din acesta fiind închis printr-un CLOSE TABLES sau CLOSE DATA de la

* 	Fereastra de comandă

DACĂ !FOLOSIT(THIS.cProjectAuditAlias)

THIS.ProjectAuditTableOpen()

ENDIF

* 	Consultați metoda ProjectAuditTableCreate() pentru lista de câmpuri

INSERT INTO (THIS.cProjectAuditAlias) ;

VALORI (LOWER(JUSTPATH(THIS.oProjectInfo.Name)), ;

JUSTFNAME(THIS.oProjectInfo.Name), ;

tcActivity, ;

tcParameter, ;

THIS.cSessionId, ;

DATETIME())

ENDIF

Acum că toate cârligele pentru evenimente umplu masa, ce poți face cu ele? Chiar dacă există controlul codului sursă, ne place să vedem când fișierul a fost modificat cel mai recent pe server:

SELECTAȚI cProjFile AS cName, ;

PADR.(mFileName,60) AS cFile, ;

cSessionId, ;

MAX(tActualizat);

DIN projectaudit ;

WHERE cActivity = „Modificat” ;

ȘI „program1.prg” $ mFileName ;

GROUP BY cProjFile, cFile ;

ÎN CURSOR curTemp

De asemenea, putem vedea de câte ori a fost deschis un proiect:

SELECTAȚI cProjFile AS cName, ;

COUNT(*) AS nCount ;

DIN projectaudit ;

WHERE cActivity = „Deschis” ;

GROUP BY cProjFile ;

ÎN CURSOR curTemp

Acestea sunt exemple banale, desigur, dar detaliile sunt acolo în tabelul pentru arhivarea dvs. și dezvoltarea codului SQL este ceea ce facem pentru a ne câștiga existența, așa că bucurați-vă.
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Cum se generează copii de rezervă automate ale metadatelor

Visual FoxPro generează un fișier de rezervă atunci când un dezvoltator modifică un fișier de program. Fișierul .bak este generat când programul modificat este salvat. Nu toate obiectele VFP primesc această caracteristică de siguranță atunci când sunt modificate. Deci, un dezvoltator este lăsat în așteptare? Evident că nu, deoarece scriem despre acest subiect în acest capitol <g>. Exemplul phkDevelopment projecthook folosește metoda QueryModifyFile pentru a apela metoda personalizată ModifyFileBackup. Acest cod copiază fișierele de metadate înainte de a trece la designerul ales. Trebuie remarcat faptul că fișierul este copiat chiar dacă dezvoltatorul nu salvează nicio modificare de la designer.

Codul din Lista 15.6 a fost preluat de pe FoxWiki, care se află la www.Fox.Wikis.com. Gurul VFP Jim Booth a postat-o pe această bază de cunoștințe incredibilă. Această rutină copiază toate fișierele de metadate diferite într-un fișier separat numit același, dar cu o extensie diferită. La fel ca și limitarea fișierului de backup al programului, este păstrat doar un nivel de backup.

Lista 15.6 Acest cod se găsește în metoda ModifyFileBackup a hook-ului de proiect phkDevelopment. Acest cod copiază diferitele fișiere de metadate într-un fișier de rezervă atunci când sunt modificate.

LPARAMETERS toFile

* 	Procesați numai dacă proiectul necesită această funcționalitate

DACĂ ASTA.lCreateBackupFile

* 	Continuați și procesați backupul

ALTE

ÎNTOARCERE

ENDIF

LOCAL lcFile && Tabel de metadate ale fișierului

LOCAL lcFpt && Fișier memo metadate asociat

LOCAL lcBak && Numele copiei de rezervă pentru tabel

LOCAL lcFptBak && Numele backuo-ului pentru memoriu

LOCAL lcOldSafety && Salvați setarea pentru a reseta Siguranța

lcOldSafety = SET(„SIGURANȚĂ”)

lcFile = UPPER(toFile.Name)

lcBak = SUBSTR(lcFile,1,LEN(lcFile)-3) + „SCT”

OPRITĂ SIGURANȚA

* 	Nu este nevoie să se ocupe de PRG-uri, DBF-uri de când primesc

* 	copiat de rezervă nativ

FACE CAZ

CASE RIGHT(lcFile,3) = „SCX”

lcFpt = SUBSTR(lcFile,1,LEN(lcFile)-3) + „SCT”

lcBak = SUBSTR(lcFile,1,LEN(lcFile)-3) + „SXK”

lcFptBak = SUBSTR(lcFile,1,LEN(lcFile)-3) + „STK”

CASE RIGHT(lcFile,3) = „VCX”

lcFpt = SUBSTR(lcFile,1,LEN(lcFile)-3) + „VCT”

lcBak = SUBSTR(lcFile,1,LEN(lcFile)-3) + „VXK”

lcFptBak = SUBSTR(lcFile,1,LEN(lcFile)-3) + „VTK”

CASE RIGHT(lcFile,3) = „FRX”

IcFpt = SUBSTR(lcFile,1,LEN(lcFile)-3) + „FRT” lcBak = SUBSTR(lcFile,1,LEN(lcFile)-3) + „FXK” lcFptBak = SUBSTR(lcFile,1,LEN(lcFile) -3) + „FTK” CAZĂ DREAPTA(lcFile,3) = „MNX”

lcFpt = SUBSTR(lcFile,1,LEN(lcFile)-3) + „MNT” lcBak = SUBSTR(lcFile,1,LEN(lcFile)-3) + „MXK” lcFptBak = SUBSTR(lcFile,1,LEN(lcFile) -3) + „MTK” CAZĂ DREAPTA(lcFile,3) = „LBX”

lcFpt = SUBSTR(lcFile,1,LEN(lcFile)-3) + „LBT” lcBak = SUBSTR(lcFile,1,LEN(lcFile)-3) + „LXK” lcFptBak = SUBSTR(lcFile,1,LEN(lcFile) -3) + "LTK" ALTELOR

SETARE SIGURANȚĂ &lcOldSafety

ÎNTOARCERE

ENDCASE

IF FILE(lcBak)

ȘTERGE FIȘIER &lcBak

ENDIF

COPIEAZĂ FIȘIER (lcFile) ÎN (lcBak)

DACĂ NU EMPTY (lcFpt)

IF FILE(lcFptBak)

ȘTERGE FIȘIER &lcFptBak

ENDIF

COPIEAZĂ FIȘIER (lcFpt) ÎN (lcFptBak)

ENDIF

SETARE SIGURANȚĂ &lcOldSafety

ÎNTOARCERE
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RAS Project Builder

RAS Project Builder (frmProjectBuilder în CPhkBase) este o combinație a casetei de dialog VFP Project Build, a casetei de dialog Build Version și a casetei de dialog Project Information. De câte ori ați realizat ultima construcție de producție de aur și ați aflat că ați uitat să dezactivați codul de depanare în dialogul Informații despre proiect, rezultând o executare de 50 de megaocteți pe cele 500 de CD-uri care tocmai au fost tăiate? Acest dialog reunește toate setările compilatorului, astfel încât să puteți construi executabilul cu toate informațiile în fața dvs. la un moment dat.

Este important de reținut că există mai multe caracteristici în RAS Project Builder (vezi Figura 5.4) care funcționează împreună cu RAS ProjectHook, dar nu este necesar. De fapt, nu există nicio cerință pentru niciun proiecthook. Singura cerință este ca un proiect (sau mai multe) să fie deschise.

Caracteristicile care nu sunt disponibile fără RAS ProjectHook sunt caseta de selectare Process Project Audit Trail, caseta de selectare și caseta de text Clean Printer Information from Reports, butonul de comandă Activare proiect, butonul de comandă Reset Field Mapping și pagina Field Mapping din cadrul paginii. Restul opțiunilor sunt disponibile pentru toate proiectele.

Deci, ce legătură are acest produs cu secțiunea projecthook a acestei cărți? Există mai multe exemple de cod în interiorul acestui instrument care demonstrează obiectul proiectului, cârligele de proiect și diferitele proprietăți, evenimente și metode asociate acestora.

Figura 15.4 Generatorul de proiecte RAS în acțiune. Rețineți butonul „PB” adăugat în bara de instrumente din partea de sus a ecranului. Acest buton este instanțiat atunci când proiectul phkDevelopment (sau subclasă) este instanțiat.

Există foarte puține metode în obiectul proiectului, dar acest utilitar le folosește pe ambele cele importante. Prima este metoda Build a obiectului de proiect. La început am folosit comanda build, dar există unele caracteristici neacceptate de comandă care sunt acceptate de metodă. Metoda Build acceptă afișarea erorilor de construire când construirea este finalizată și, de asemenea, gestionează suport pentru regenerarea ID-urilor componentelor pentru diferitele opțiuni de server COM. A doua metodă folosită este metoda Clean. Această metodă împachetează fișierul de metadate ale proiectului. Această opțiune poate fi accesată și în meniul Proiect VFP.

Mai multe proprietăți ale obiectului proiectului sunt accesate și demonstrate prin acest utilitar. Toate informațiile despre versiune care se află pe pagina versiunii sunt accesate prin intermediul proprietăților VersionComment, VersionCompany, VersionCopyright, VersionDescription, VersionLanguage, VersionNumber, VersionProduct și VersionTrademarks. Posibilitatea de a seta versiunea Auto Increment este legată de proprietatea AutoIncrement, Executable criptat de proprietatea Encrypted și setarea Cod de depanare la proprietatea Debug. Numele și clasa projecthook sunt afișate pe pagina Despre și sunt accesate prin proprietățile ProjectHookClass și ProjectHookLibrary. Același lucru este valabil și pentru furnizorul de cod sursă prin proprietatea SCCProvider.

Este important să vorbim și despre grupul de opțiuni de comutare Dezvoltare/Producție. Opțiunea de producție folosește implicit versiunea pentru a recompila toate fișierele, a afișa erorile și setează rapoartele pentru a fi curățate de posibilele informații despre imprimanta de dezvoltare. Am stabilit că aceste setări sunt cele mai bune pentru mediul nostru de dezvoltare. Setarea Producție face, de asemenea, o setare strictdate la i, astfel încât să nu existe mesaje ambigue de la introducerea datei utilizatorului în aplicația de producție. Setarea Dezvoltare face invers și stabilește o dată strictă la 2, așa că suntem alertați cu privire la problemele anului 2000 pe care codul nostru le-ar fi introdus din neatenție. Setările comutatorului Dezvoltare/Producție pot fi înlocuite prin setarea lor prin interfață după alegerea tipului de construcție pe care doriți să o efectuați. De exemplu, dacă doriți să nu afișați erori și să nu curățați rapoartele despre posibilele informații despre imprimante de dezvoltare pentru o versiune de producție, faceți clic pe casetele de selectare pentru a reflecta dorințele dvs.

Utilizăm cu succes acest instrument de la sfârșitul anului 1999. În mod natural, a trecut prin unele îmbunătățiri prin sugestiile beta testerului. Îl plasăm în domeniul public, astfel încât alții să poată beneficia de acest utilitar la îndemână. Nu are nicio garanție și a fost dezvoltat inițial ca un instrument de învățare, dar de-a lungul timpului și-a luat viața proprie, ca multe instrumente de dezvoltare. Sursa este inclusă în fișierele de descărcare pentru dezvoltatori disponibile la www.hentzenwerke.com.
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Concluzie

Instrumentele de management de proiect sunt destul de incluzive în Visual FoxPro. Când vă confruntați cu o limitare, este posibil să vă puteți construi propria extensie printr-un proiect hook sau un alt instrument de dezvoltator, așa cum am făcut cu RAS Project Builder. Sperăm că acest capitol v-a adus un cod util de implementat în mediul dumneavoastră de dezvoltare și, chiar mai important, vă va inspira să construiți instrumente și extensii care vor îmbunătăți IDE-ul VFP și experiența dumneavoastră de dezvoltare.
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Capitolul 16 - Crearea rapoartelor

"Este la fel de fiecare dată cu progresul. Mai întâi te ignoră, apoi spun că ești supărat, apoi periculos, apoi se face o pauză și apoi nu poți găsi pe nimeni care să nu fie de acord cu tine." (Tony Benn citat în „The Observer”, Londra, 6 octombrie 1991)

Dezvoltatorii Visual FoxPro nu au avut prea multe de ce să aclama de înainte de lansarea Visual FoxPro 3.0 când vine vorba de a avea un designer de rapoarte de ultimă generație. Realitatea dezvoltării software este că rapoartele sunt cruciale. Rapoartele sunt folosite de clienții noștri pentru a analiza terabytes de date pe care aplicațiile îi urmăresc. Aceste rezultate pot fi folosite pur și simplu pentru a reaminti utilizatorului numărul de telefon al șefului sau pentru a permite CEO-ului să decidă asupra unei fuziuni importante de miliarde de dolari. Acesta este motivul pentru care procesul de creare a rapoartelor este atât de important și de ce dezvoltatorii VFP au nevoie de un set serios de trucuri atunci când folosesc bunul Report Designer.

Obiectivul principal al majorității aplicațiilor de baze de date este stocarea informațiilor importante care sunt esențiale pentru persoanele care utilizează sistemele. Următoarea funcționalitate cea mai critică este procesul de rezumare și raportare a informațiilor, astfel încât să poată fi utilizate de companie pentru a lua decizii pe baza datelor care sunt urmărite.

Am auzit dezvoltatori experimentați spunând că cel mai bun mod de a crea rapoarte este să angajezi pe cineva căruia îi place să le facă. Ei complet nu doresc să creeze rapoarte. În trecut, am auzit dezvoltatori spunând lucruri precum „Nu fac date”, dar în ultimul timp începem să auzim mantra „Nu fac rapoarte”. Ieșirea datelor este scopul majorității aplicațiilor. Unii clienți doresc rezultate elaborate care ar putea fi folosite pentru a publica o carte sau o broșură de vânzări, alții au nevoie doar de o listă cu cele mai recente cifre de vânzări pentru a se asigura că obiectivele sunt îndeplinite zilnic. Sincer, acestui autor îi place să facă reportaje. Rapoartele sunt linia vitală a clienților pentru care lucrăm și avem o mare plăcere atunci când datele brute sunt transformate în informații care le permit clienților să-și analizeze afacerea.

Ieșirea dintr-o aplicație este un loc excelent pentru a începe atunci când proiectați o nouă aplicație. Când ne adunăm cu un client pentru a începe să colectăm cerințe, inițial ne întrebăm care este scopul sistemului pentru client. Următorul pas este definirea rapoartelor și a rezultatelor pe care trebuie să le genereze și să le analizeze. S-ar putea să vă întrebați, de ce să începeți cu rapoartele? Clientul declară diferitele entități și atribute în timp ce discută rezultatele. Acestea se traduc cu ușurință în elemente de date din modelul de date.

Trucul adevărat este ca VFP Report Designers să se răsucească și să se întoarcă în direcțiile de care au nevoie clienții. Acest capitol va aborda câteva tehnici de bază și interesante pentru a vă ajuta să generați unele dintre rapoartele cerute de clienți.

Este important să rețineți că în acest moment multe dintre sfaturile prezentate în acest capitol se aplică atât rapoartelor, cât și etichetelor. Există multe asemănări între Report și Label Designer, aproape ca și cum ar fi același cod intern. Vedem două diferențe semnificative între designeri. Primul este dialogul New Label prezentat pentru o nouă etichetă care listează toate formatele Avery Label disponibile pentru selecție. A doua diferență este modul în care paginile sunt definite implicit în dialogul Fișier|Configurare pagină... atunci când sunt create rapoarte și etichete noi. Rapoartele se imprimă implicit pe pagina imprimabilă, în timp ce etichetele se imprimă implicit pe întreaga pagină.

Toate mostrele prezentate în acest capitol pot fi găsite în proiectul CH16.pjx. Toate mostrele de raport pot fi rulate din formularul Ch16Rpts.

Figura 16.1 Formularul Ch16Rpts demonstrează toate eșantioanele și sfaturile discutate pe parcursul acestui capitol
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Raportați regula #1

Regula numărul unu pentru obținerea de rapoarte de succes în VFP este să lăsați Visual FoxPro să facă ceea ce face cel mai bine, adică să manipuleze datele. Utilizarea tehnicilor dovedite, cum ar fi SQL-Selects sau chiar a unor comenzi de date Xbase de modă veche, cum ar fi scan..bndscan, pentru a procesa datele și a crea un cursor pentru formatarea raportului, este cea mai bună practică care a funcționat de ani de zile. Aceasta este metodologia Keep It Simple Simon (KISS) pe care am folosit-o pentru a crea rapoarte cu VFP Report Designer.
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Tehnici de formatare

Personajul lui Billy Crystal, Fernando, din Saturday Night Live, a inventat expresia: „Nu este cum te simți, ci este cum arăți și eu arăt minunat”. Acest lucru nu poate fi spus suficient când vine vorba de rapoarte. Acesta este motivul pentru care vom aborda unele dintre problemele „frumoase” care ne-au ajutat de-a lungul anilor și care pot îmbunătăți rapoartele pe care le generați.

Cum să accelerați imprimarea cu fonturile de imprimantă

Dezvoltatorii FoxPro s-au mutat în lumea Windows în zilele 2.x. Unul dintre marile avantaje ale versiunii Windows a fost inventarea rapoartelor grafice și capacitatea de a avea cu ușurință diferite fonturi. Cu această caracteristică nouă a fost un mare compromis. Rapoartele grafice sunt mult mai lente decât omologii lor DOS. Motivul pentru aceasta este că imaginea este trimisă la imprimantă în loc de fluxul ASCII al rapoartelor DOS. Același lucru este valabil și astăzi în Visual FoxPro.

O modalitate de a accelera rapoartele generate din Report Designer este utilizarea fonturilor specifice imprimantei în rapoarte. Deci, ce fonturi sunt cele mai bune? Acest lucru va depinde de imprimantele pe care le folosesc clienții dvs. De exemplu, clienții noștri în cea mai mare parte au standardizat pe Hewlett Packard LaserJets. Aceste imprimante au CG Times și Univers native. Mulți producători de imprimante includ fonturi True Type în memorie.

Cum se generează efectul „greenbar” (Exemplu: GreenBar.frx, GreenBar2.frx)

Efectul „greenbar” este o întoarcere la hârtia care a fost folosită pe imprimantele de mare viteză asociate în mod obișnuit cu cadrele centrale mari de fier. Lucrarea are bare alternative verzi și albe pentru a-i ajuta pe cei care citesc raportul să urmărească datele pe o foaie largă de hârtie.

Crearea unui facsimil de hârtie verde este la fel de simplă ca tipărirea câmpurilor dreptunghiulare umbrite. În logica Print When, plasați codul similar cu următorul:

MOD(RECNO(),2) = 0

Sistemul grupului de utilizatori GreenBar.frx Pagina 1	

Dezvoltat ca un exemplu pentru cartea excelentă
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Figura 16.2 Controlul tipăririi Când unui dreptunghi umbrit pe banda de detalii creează efectul Bară verde

Funcția MOD() preia primul parametru, îl împarte la al doilea parametru și returnează restul. În codul pe care îl avem aici, logica Print When este adevărată pentru fiecare altă înregistrare, deci alternativă

înregistrările primesc un fundal umbrit. Măriți al doilea parametru pentru a reduce frecvența umbririi.

Există o a doua tehnică (demonstrată în eșantionul GreenBar2.frx) pentru a avea mai multe linii de detalii în ordine consecutivă pentru a avea umbrire. Această tehnică urmează aceeași premisă cu dreptunghiul umbrit și folosește tipărirea când are un cod similar cu acesta:

INLIST(MOD(RECNO(),6), 4, 5, 0)

Exemplul de cod va avea ca efect tipărirea a trei înregistrări fără umbrire urmate de trei înregistrări cu umbrire. Implementarea pontului este simplă. Mai întâi dă-ți seama câte linii de detalii vrei umbrite și dublează-l. Acest număr este al doilea parametru al funcției MOD(). Restul parametrilor funcției inasto sunt resturile pe care modo le va returna. Va trebui să faceți din jumătate din restul parametrilor inlisto. Dacă doriți ca umbrirea să fie inversată, schimbați codul din Imprimați când:

INLIST(MOD(RECNO(),6), 1, 2, 3)

Funcționează bine dacă eliminați chenarul dreptunghiului umbrit în această situație, altfel veți avea linii între fiecare linie de detaliu. Selectarea dreptunghiului umbrit și schimbarea dimensiunii stiloului în „niciunul” prin meniul Format poate realiza acest lucru.

Din experiența noastră, vă recomandăm să reduceți numărul de linii și casete dreptunghiulare din raport, deoarece este greu de lucrat cu ele, deoarece plasarea pe raport va diferi de la imprimante. Cel mai bine este să testați un exemplu simplu pe diferitele imprimante ale clienților înainte de a estima timpul de dezvoltare pentru un raport cu linii și casete pe tot aspectul. De asemenea, experiența noastră este că umbrirea poate îmbunătăți aspectul și poate face obiectele să iasă în evidență.

Cum se generează casete de verificare în rapoarte (Exemplu: Checks.frx)

Câți clienți sunt obișnuiți să vadă .t. sau .f. pe un raport pentru un câmp logic și câți dintre ei înțeleg sintaxa logică? Suntem siguri că există câțiva utilizatori care pot răspunde da la asta, dar câți dezvoltatori doresc să explice ce înseamnă asta unui vicepreședinte al General Motors?

Pentru a salva un pic de față și a trebuit să scrieți o pagină de documentație, astfel încât Directorul de Resurse Umane să explice .t. și .f. valori logice pentru VP de Resurse Umane, dezvoltatorul vine cu o soluție simplă - transforma valorile logice în caractere în expresia raportului. Există mai multe tehnici care funcționează:

IIF(lVizitat,"Y","N") && Afișează Da sau Nu

IIF(lVizitat, „Da”, „”) && Afișează numai elementele pozitive

TRANSFORM(lVizitat, „Y”) && Afișează „Y” sau „N”

Deși aceste opțiuni sunt utile, nu sunt suficient de picante pentru ochii unui VP. Așa că trebuie să venim cu o altă alternativă. Ceea ce mărește cu adevărat într-un dezvoltator experimentat este o declarație de genul „Păi,

Rapoartele Microsoft Access au casete de selectare mici în rapoarte, la fel ca formularul meu de introducere a datelor. Vrei să spui că aplicațiile Visual FoxPro nu pot face acest lucru? După cum vă puteți imagina, soluția este destul de ușoară atunci când o provocare este prezentată astfel <g>.

Aripi în ajutor! Folosiți o tehnică asemănătoare cu prima linie de cod din exemplele discutate. Folosind immediate-if (uf), imprimați un caracter din setul de caractere Wingdings în locul fontului implicit al raportului. Deci vă întrebați, de unde naiba știu valoarea ASCII a Wingding-ului care arată ca x? Există un applet care vine cu toate sistemele de operare Windows ca Harta Caracterelor (vezi Figura 16.3).

Făcând clic pe personajul ales, îl va plasa în zona „Caractere de copiat”. Appletul arată, de asemenea, valoarea ASCII a caracterului în colțul din dreapta jos, care poate fi utilizată în combinație cu tasta ALT pentru dezvoltatorii cu o preferință a tastaturii. Reveniți la VFP și inserați caracterul în dialogul pentru expresia raportului în partea corespunzătoare a instrucțiunii uf (vezi Figura 16.4). Schimbați fontul pentru obiect cu fontul Wingdings și sunteți bine ca ați făcut. Figura 16.5 prezintă un exemplu de raport în modul proiectant, Figura 16.6 arată raportul în modul de previzualizare.

Figura 16.3 Aplicația Windows Character Map este o sursă excelentă de grafice care poate fi utilizată în rapoarte (și formulare) fără greutatea unui fișier graphie

Figura 16.4 Odată ce ați copiat caracterul în Character Map, lipiți-l în expresia raportului

Figura 16.5 După schimbarea fontului în Wingdings, acesta va face codul necitit în Report Designer. Este încă lizibil în dialogul Report Expression.
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Figura 16.6 Lucrul ușor cu casetele de selectare se plătește cu un raport cu aspect profesional

Trebuie menționat că această tehnică funcționează și pentru datele afișate într-o grilă și pe formulare.

Cum se reduce/mărește spațiul alb la tipărirea câmpurilor de note

(Exemplu: WhiteSpace. frx/.prg)

Cantitatea de informații prezentate în câmpurile de note poate consuma mai multă hârtie decât ne-am dori.

Am găsit că cea mai ușoară modalitate de a reduce consumul de hârtie în exces în rapoarte este de a minimiza spațiul alb din câmpurile de memorare la imprimarea raportului. Aceeași tehnică poate fi folosită și pentru a dubla spațiu șiruri lungi de text.

Acest sfat este destul de simplu, deoarece dimensionarea obiectelor este o sarcină comună de dezvoltare atunci când proiectați rapoarte. Vârful se concentrează pe înălțimea obiectului. În Figura 16.7 vedem obiectul din dreapta mai scurt decât cel din stânga. Acest lucru a fost realizat prin dimensionarea fundului în sus cu tastatura. Puteți utiliza mouse-ul pentru a face acest lucru sau o combinație a tastelor Shift plus tastele săgeți sus sau jos. Trucul este să mutați partea de jos a obiectului chiar și cu linia de lângă expresia obiectului.

Tehnica de dimensionare discutată în această secțiune funcționează numai dacă nu aveți setat Snap to Grid pentru raport. Dacă opțiunea Snap to Grid este activată, obiectul nu va face mici modificări incrementale la dimensiunea obiectului; mai degrabă va face modificări de dimensiune în raport cu dimensiunea grilei setată pentru raport.
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Figura 16.7 Acesta este modul de proiectare a două câmpuri din raportul WhiteSpace.frx. Singura diferență este că cel din stânga este „mai înalt”, iar cel din dreapta a fost „micșorat”.

Exact opusul, creșterea înălțimii obiectului față de valoarea implicită VFP, poate oferi beneficiul unui spațiu alb suplimentar pentru a lăsa loc pentru note sau pentru a îmbunătăți lizibilitatea raportului. Cheia pentru spațiul alb suplimentar este să nu-l întindeți dincolo de indicatorul de a doua linie (subliniere).

Același sfat poate fi folosit și pentru spațiile albe ale liniilor de detaliu. Doar micșorați toate câmpurile de pe linie și îndepărtați spațiul alb dintre ele și bara de bandă. Acest lucru poate salva pagini și pagini din rapoarte lungi. De asemenea, poate însemna diferența dintre imprimarea unui raport cu o singură pagină și unul care ocupă doar câteva rânduri pe a doua pagină.

Cum să afișați un câmp în modul de previzualizare, dar nu de tipărire (Exemplu:

GreenBar.frx)

Ați dorit vreodată să includeți comentarii pentru utilizatorul final într-un raport, dar să nu le faceți să apară în rezultatul final tipărit? Acest mic truc permite ca elementele să fie văzute în modul de previzualizare a raportului, dar nu le include în hard сору tipărit al raportului.

Acest lucru se realizează prin adăugarea următoarei condiții Print When la un obiect de raport:

NOT WEXIST(„Se imprimă...”)

Exemplul de capitol utilizat este raportul GreenBar. Există o notă pentru a trimite raportul președintelui grupului. Apare doar în modul de previzualizare.

Un alt motiv pentru care putem vedea că această caracteristică este utilă este pentru rapoartele care imprimă informații securizate. De exemplu, luați un raport al managerului care enumeră salariile angajaților. Accesul de securitate este acordat utilizatorilor autorizați pentru a rula raportul. Dacă imprimă accidental raportul către o imprimantă într-o zonă cubică și apoi iau un apel telefonic și uită că au tipărit raportul, pot apărea probleme evidente. Este posibil ca angajații să-l vadă și ar fi probleme în paradis. Pentru a evita deloc tipărirea informațiilor securizate, puteți folosi această tehnică pentru a vă proteja împotriva potențialelor probleme.

Cum să minimizezi durerea folosind linii și casete (Exemplu: PeriodYtd.frx)

Am spus de cât timp am folosit versiunile pentru Windows ale FoxPro și Visual FoxPro că utilizarea liniilor și casetelor trebuie evitată dacă este posibil. Motivul pentru aceasta este simplu, în funcție de imprimanta sau driverele de imprimantă implicate. Rândurile tind să aibă o minte proprie despre locul în care doresc să imprime pe o pagină. Va pluti, uneori cu câțiva pixeli și alteori cu mai mulți. Ne place să ne referim la această problemă drept „sindromul liniei plutitoare”. Deci, ce trebuie să faceți atunci când un client i-a cerut să reproducă un formular care seamănă mai mult cu hârtie milimetrată decât cu un raport folosit pentru a analiza o afacere? Trebuie doar să urmați câteva dintre regulile pe care le-am dezvoltat.

Am afirmat deja regula numărul unu, limitează utilizarea liniilor. Acest lucru nu înseamnă să reveniți la sublinierea titlurilor cu semnul minus. Folosim linii pentru a sublinia titlurile paginilor noastre și le folosim generos pentru a sublinia anteturile și subsolurile de grup pentru a diferenția blocurile de detalii. Aceste tipuri de linii nu provoacă durerea pe care am descris-o în paragraful anterior. Utilizarea corectă a lățimii și stilului stiloului va îmbunătăți rapoartele.

Regula numărul doi este să folosiți obiectul dreptunghi atunci când creați o cutie. Am moștenit o serie de rapoarte care conțineau fiecare o caracteristică particulară - dezvoltatorii originali au folosit patru linii (în loc de dreptunghi) pentru a afișa o casetă. Prima dată când trebuie să extindeți cutia făcută cu linii va fi suficientă pentru a vă încărunți părul. Realizarea fiecărei linii este o muncă obositoare. Dacă raportul suferă de „sindromul liniei plutitoare”, acesta va fi mărit doar cu diferitele laturi ale formularului care se vor îndepărta unele de altele.

În cele din urmă, dacă o linie este verticală și este folosită în mai multe benzi, trageți o linie peste toate benzile în care este nevoie. Nu încercați niciodată să utilizați o linie separată în antetul grupului, banda de detalii și subsolul grupului. Veți economisi bătăi de cap mai târziu, când mențineți raportul, trasând o singură linie peste benzi. În acest fel, nu va trebui să vă faceți griji cu privire la alinierea lor corectă sau că problema liniei plutitoare va cauza probleme de suport. Celălalt beneficiu este că liniile se întind, de asemenea, pe măsură ce banda se întinde atunci când este rulat raportul.

Cum să folosești float în avantajul tău

Funcționalitatea float a Report Designer este critică în formatarea rapoartelor cu câmpuri care sunt tipărite sub o notă cu mai multe linii.

Conținutul unui câmp de memorare tipări adesea mai multe rânduri. Ce se întâmplă cu obiectele care urmează să fie tipărite după sau sub câmpul notă? Dacă nu sunt marcate să plutească sau să fie fixate în raport cu partea de jos a benzii, acestea vor fi tipărite în interiorul (de sus sau dedesubt) informațiile de memorare. Aceasta este de obicei o caracteristică nedorită. Puneți celelalte obiecte sub câmpul extensibil și marcați-le fix în raport cu partea de jos a benzii sau setați proprietatea de plutire a obiectului. Banda își va regla înălțimea în funcție de conținutul notificărilor în timpul tipăririi, iar celelalte articole vor rămâne întotdeauna sub note. Dacă notele sunt goale, nu li se va aloca spațiu în bandă și totul de mai jos se va muta în sus.

Cum să imprimați simboluri marcatori cu câmpuri extensibile (Exemplu:

BulletMemo.frx)

Ați imprimat vreodată conținutul unui câmp de notă sau unui câmp de caractere mari și ați dorit să marcați începutul acestuia cu un marcator? Există o problemă când există un obiect de raport care este extensibil și are text care se încadrează în mai multe rânduri înaintea articolului cu marcatori. Dacă nu există câmpuri extensibile înaintea articolului cu marcatori, puteți doar să puneți un marcator marcator lângă text (vezi Figura 16.8).
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Președinte: Steve Sawyer Secretar: Rick Schummer

□ Grupul de utilizatori Fox Mid-Michigan

Întâlnește a treia sâmbătă a fiecărei luni între orele 9:30-12:15.

Discuțiile informative continuă ulterior la prânz.

Grupul de utilizatori Rocky Mountain FoxPro este condus de Doug Sherman.

Grupul de utilizatori și dezvoltatori FoxPro din Chicago

Bill OConnor conduce Chicago

Grupul de utilizatori și dezvoltatori FoxPro.

]□ Sterling Heights Computer Club

Figura 16.8 Acesta este un exemplu care tipărește un marcator lângă începutul unui șir de text lung care se înfășoară la o altă linie
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Figura 16.9 Acesta este un exemplu de ceea ce se întâmplă atunci când gloanțele nu plutesc corect cu textul asociat

Soluția prezentată este aplicabilă oricăror obiecte de raport care trebuie să fie unul lângă celălalt pe un raport atunci când aceste obiecte sunt sub un alt obiect extensibil. Această problemă este ușor de rezolvat.

Creați două obiecte câmp separate. Primul este marcajul care poate fi un simplu asterisc sau puteți găsi un personaj Wingding sau un fișier imagine pentru a satisface această nevoie. Al doilea este un obiect câmp care imprimă un câmp de caractere lung. Exemplul (BulletMemo.frx) folosește combinația dintre un câmp de caractere și un câmp de memorare separate prin fluxuri de linie. Asigurați-vă că ambele câmpuri sunt setate să plutească și că obiectul raport utilizat pentru a tipări textul lung este setat la Întindere cu depășire. Câmpul glonț trebuie să fie suficient de larg pentru a se încadra parțial sub câmpul de notificări. Prin suprapunerea celor două obiecte de raport, cele două vor pluti împreună. În caz contrar, ele se vor separa, așa cum este demonstrat în Figura 16.9. Asigurați-vă că trimiteți și câmpul marcator în spate, astfel încât lățimea suplimentară să nu împiedice tipărirea obiectului de raport extensibil care imprimă textul lung.

Cum să construiți o adresă poștală fără lacune (Exemplu: Address.frx)

Adesea vedem dezvoltatori care se luptă pentru a scăpa de decalajul afișat între linia unu de adresă și oraș, stat și cod poștal. Aceasta este de obicei asociată cu linia doi de adresă populată mai puțin frecvent. Aceste lacune nu sunt de obicei preferate de clienți. De fapt, acest autor și-a câștigat odată un loc de muncă pentru dezvoltare, deoarece cunoștea câteva tehnici pentru a scăpa de „linia necompletată” de etichetele de corespondență importante ale unui potențial client.

Prima tehnică utilizează caracteristica cunoscută în mod obișnuit „Eliminați linia dacă este necompletată” care este disponibilă în caseta de dialog Print When pentru fiecare obiect de raport. Acest lucru funcționează bine pentru etichete, deoarece de obicei nu există niciun alt obiect lângă adresa etichetei. Acest lucru nu este întotdeauna adevărat într-un raport. Raportul poate avea o adresă în stânga și detalii despre companie în partea dreaptă a raportului. Dacă există detalii pe aceeași linie ca și linia doi de adresă, aveți probleme deoarece VFP nu poate elimina linia, deoarece nu este goală.
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Figura 16.10 Acesta este un exemplu de două adrese diferite afișate fără „golul” lăsat de o linie de adresă goală doi pe adresa DAFUG

Aici este utilă a doua tehnică. VFP Report Designer are două „caractere speciale”, virgula și punct și virgulă, care sunt tratate diferit într-o expresie de raport. Virgula concatenează elementele împreună în expresie și include un spațiu între ele. Dacă expresia concatenată este goală, se traduce într-un șir nul (s»ace<0)). Poate fi tradus literal în cod ca:

IIF(EMPTY «expresie», SPACE(О), SPACE(i)+ALLTRIM(<expresie») .

Punctul și virgulă este literalmente transformat într-un retur de cărucior și/sau un avans de linie. Dacă expresia este goală, linia este eliminată în același mod ca atunci când opțiunea „Eliminați linia dacă este necompletată”. O alta

avantajul secundar este că puteți combina și potrivi tipurile de date în acest mod. VFP se va ocupa de imprimare fără a forța dezvoltatorul să le transforme în tipul de date caracter.

Deci, cum se poate profita de aceste personaje speciale? Iată codul folosit în exemplul afișat în Figura 16.10:

cUserGroup,"("+ ALLTRIM(cAbbr) + ")"; cAdresăl; cAdresa2; ALLTRIM(cCity) + ",", cState, SPACE(1),cPostalCode

Această expresie cu o linie este utilizată în loc de patru obiecte de raport text individuale. Dezavantajul acestei tehnici este că aveți un singur font pentru întregul obiect.

Cum să utilizați subtitrările câmpurilor DBC în rapoarte (Exemplu: DynCaption.frx)

Containerul bazei de date VFP vă permite să introduceți subtitrări pentru fiecare câmp dintr-un tabel sau vizualizare.

Din păcate, Report Designer nu profită de această caracteristică în același mod ca și Form Designer. Doar obțineți câmpul într-un obiect de raport de câmp atunci când glisați un câmp din mediul de date raport. Câmpul Legendă nu este plasat în raport, așa cum este pe un formular. Tehnica descrisă în această secțiune permite rapoartelor să citească în mod dinamic legendele containerului bazei de date prin intermediul funcției DBGETPROP().

Tehnica este implementată folosind un obiect câmp, deoarece un obiect etichetă de raport nu poate fi modificat dinamic în timpul rulării. În loc să codificați din greu anteturile coloanei sau etichetele câmpurilor din raport, puteți obține câmpul Legendă din containerul bazei de date. În obiectul câmp, introduceți o expresie care este modelată după următoarea sintaxă:

DBGETPROP(<tablename.fieldname>, „FIELD”, „CAPTION”)

Acest lucru oferă dezvoltatorilor o flexibilitate optimă prin modificarea subtitrărilor câmpurilor din baza de date. Dacă utilizatorul dorește să fie schimbată legenda raportului, trebuie doar să actualizați legenda câmpului din baza de date. Marele dezavantaj este performanța mai lentă, deoarece raportul trebuie să acceseze containerul bazei de date de fiecare dată când expresia este evaluată. Un avantaj este că toate rapoartele care utilizează această tehnică vor avea aceeași legende pentru același câmp. Consecvența este un lucru bun. De asemenea, puteți face modificări la anteturile coloanei și etichetele câmpurilor fără a fi nevoie să recompilați aplicația sau să trimiteți separat un fișier de raport actualizat pentru a reflecta modificarea solicitată.

Copyright 2000 de către Marcia Akins, Andy Kramek și Rick Schummer Toate drepturile rezervate

Probleme cu banda

Această secțiune a capitolului de raport nu are nimic de-a face cu problemele industriei muzicale, mai degrabă cum să utilizați funcțiile de grupare a datelor din VFP Report Writer pentru a vă ușura crearea raportului.

Cum să evitați anteturile orfane și subsolurile văduve (Exemplu:

HdrFootCutoff.frx)

Un antet de grup este orfan atunci când nu există linii de detalii tipărite între acesta și sfârșitul paginii.

Acest lucru se întâmplă atunci când aveți suficient spațiu la sfârșitul unei pagini de raport pentru a imprima antetul grupului, dar nu suficient spațiu pentru a imprima linia de detalii. Subsolul grupului este văduv atunci când nu există suficient spațiu între ultima linie de detaliu și sfârșitul paginii de raport pentru a imprima subsolul grupului.

Antetul grupului orfan este ușor de corectat, deoarece VFP Report Designer are un mecanism încorporat pentru a-l gestiona. Iată pașii pentru implementarea acestei tehnici:

1. 	Mai întâi accesați banda de detalii și obțineți înălțimea benzii. Faceți dublu clic pe bara de detalii pentru a afișa dialogul Detaliu.

2. 	Copiați înălțimea benzii în clipboard.

3. 	Treceți la dialogul Grupare date (Meniu Raport, Grupare date...) și selectați grupul pe care încercați să îl împiedicați să rămână orfan.

4. 	În partea de jos a paginii, veți vedea un rotor „Începeți grupul pe o pagină nouă când este mai mic de”. Lipiți înălțimea detaliului în acest spinner. Această valoare trebuie să fie mai mare decât înălțimea benzii de detalii. Preferăm să setăm acest lucru la înălțimea benzii de detalii plus înălțimea antetului de grup pentru a ne asigura că putem încadra cel puțin o înregistrare de detaliu și antetul grupului.

Designerul de raport VFP verifică după imprimarea fiecărui subsol de grup pentru camera rămasă în partea de jos a paginii pentru a vedea dacă se poate potrivi cu următorul antet de grup. Acest calcul al spațiului de pagină ia în considerare spațiul de început al grupului pe care l-ați introdus la pasul 4 de mai sus. Dacă există loc atât pentru antetul grupului, cât și pentru o linie de detaliu, antetul este tipărit.

Nu există o capacitate încorporată de a gestiona subsolurile văduve, dar, din fericire, există o soluție destul de simplă:

1. 	Proiectați benzile de subsol pentru detalii și grup și funcționează exact așa cum le doriți pentru raport.

2. 	În acest moment, trebuie să extindeți dimensiunea liniei de detaliu cu înălțimea subsolului grupului. Veți insera un nou obiect în banda de detalii.

3. 	Apoi creați un obiect câmp în subsolul grupului care este înălțimea subsolului grupului. Acest obiect va fi un câmp inactiv care nu se tipărește niciodată, astfel încât lățimea poate fi orice doriți. Am plasat ceva text în expresia de genul „Footer Placeholder, never printed”. Îl creăm în banda de subsol deoarece este dimensionat la înălțimea completă a benzii. Acest lucru ne oferă imaginea de care avem nevoie pentru a-l dimensiona corect.

4. 	În caseta de dialog de proprietăți pentru acest obiect de câmp inactiv, asigurați-vă că accesați dialogul Print When și setați „Eliminați linia dacă este necompletat” și plasați un .f. în „Tipărește numai când

caseta de text expresia este adevărată". Această setare asigură că acest câmp inactiv nu este niciodată tipărit.

5. 	Acest obiect este mutat în banda de detalii și plasat în partea de jos a benzii de detalii. Ar trebui să se lovească de cel mai jos obiect din banda de detalii, cu excepția cazului în care doriți spațiu între benzile de detalii din raportul tipărit. Mutați strâns bara de bandă de detalii pe acest obiect după ce l-ați poziționat.

Ceea ce realizează acest lucru este să păcăliți Visual FoxPro să creadă că linia de detalii are nevoie de mai mult spațiu decât are cu adevărat. VFP Report Designer consideră acum că are nevoie de suficient spațiu pentru detaliile reale, plus subsolul grupului. Dacă are suficient spațiu în partea de jos a paginii, imprimă detaliile și elimină substituentul de subsol. Acum subsolul se potrivește bine pe pagină când este tipărită. Dacă linia de detaliu falsificată nu se potrivește, atunci se trece la pagina următoare și subsolul are compania a cel puțin o linie de detaliu și nu mai este văduv.

Cum să aveți a doua benzi de rezumat cu EOF() (Exemplu:

EOFBreakIt.frx)

Designerul nativ de raport oferă benzi de titlu și rezumat pentru a tipări informații la începutul și la sfârșitul raportului. Aceste benzi oferă unui dezvoltator posibilitatea de a pune aceste informații rezumative pe propria pagină sau de a le include în fluxul raportului. Ce se întâmplă dacă doriți ca unele numere rezumate să fie tipărite după ultima linie de detaliu și apoi să aveți o pagină de rezumat completă cu statistici de raport pe o pagină separată (ideal pentru banda rezumat)?

Aici o grupare pe eofo oferă o oarecare flexibilitate suplimentară pentru dezvoltator. Oferă un subsol de bandă de grup care poate fi utilizat pentru numărări rezumative, sume și restul caracteristicilor agregate încorporate în Report Designer. Banda de rezumat încorporată poate fi apoi utilizată cu opțiunea „Pagină nouă” setată pentru a forța rezumatul raportului real la propria pagină. Banda de rezumat poate fi apoi utilizată pentru rezumatul raportului real cu un format diferit sau poate servi ca rezumat executiv.

Cum să creați pauze flexibile de control (Exemplu: EOFBreakIt.frx/prg)

Crearea unui raport care poate fi utilizat pentru diferite criterii de sortare și pauză de control este o provocare.

Reutilizarea este unul dintre obiectivele unui design bun de software, așa că putem avea reutilizabilitate cu rapoartele VFP? Această secțiune demonstrează o metodă de reutilizare a rapoartelor, arătând o soluție simplă/truc pe care l-ați putea găsi util în eliminarea necesității mai multor rapoarte care au în esență aceleași informații.

Programul EOFBreakIt și raportul corespunzător care vine cu fișierele de descărcare pentru dezvoltatori ale capitolului disponibile la www.hentzenwerke.com demonstrează această tehnică.

Construiți raportul pentru a satisface cerințele clientului. Când există pauze de grupare, în loc să utilizați câmpul(e) ca expresie, utilizați o expresie generică de nume de grup. În raportul exemplu folosim expresia cBreakGroup.

Restul tehnicii este implementat în cod SQL-Select (sau vizualizări dacă aveți această preferință) atunci când pregătiți datele pentru raport. Fiecare dintre expresiile de grupare sunt câmpuri dinamice care sunt create prin clauza as. Câmpurile virtuale sunt, de asemenea, folosite în ordinea după clauză. Acesta este modul în care se imprimă raportul cu pauze de control dinamic. Iată un exemplu de cod:

**** Executați prima versiune a raportului ****

USE v_groupsbygroupcat

SELECT *, cCategory AS cBreakGroup ;

FROM v_groupsbystate ;

COMANDĂ PRIN cBreakGroup ;

INTO CURSOR curReport

* 	Publicați raportul dacă date

DACĂ _TALLY > 0

FORMULAR DE RAPORT EOFBreakit PREVIEW NOCONSOLE

ALTE

MESAGEBOX(„Fără date de raportat!”, 0+16, _screen.Caption)

ENDIF

**** Executați a doua versiune a aceluiași raport ****

USE v_groupsbystate

SELECT *, cState AS cBreakGroup ;

FROM v_groupsbystate ;

COMANDĂ PRIN cBreakGroup ;

INTO CURSOR curReport

* 	Publicați raportul dacă date

DACĂ _TALLY > 0

FORMULAR DE RAPORT EOFBreakit PREVIEW NOCONSOLE

ALTE

MESAGEBOX(„Fără date de raportat!”, 0+16, _screen.Caption)

ENDIF

Prima instanță de raport tipărește înregistrările grupate pe categorii, a doua instanță este grupată după stare. Cheia pentru obținerea acestui set de grupare este <expresia câmpului> AS cBreakGroup.

CBreakGroup poate fi, de asemenea, un câmp virtual pe vizualizare. Folosim această tehnică destul de puțin în munca noastră de zi cu zi, deoarece reduce numărul de rapoarte de menținut într-un sistem mare. Destul de des vedem comunitatea în ieșire cu mult înainte ca utilizatorii să o facă. Acest lucru poate economisi timp enorm în majoritatea proiectelor de dezvoltare.

Cum să construiți două (sau mai multe) seturi de linii de detalii (Exemplu: PeriodYtd.frx)

Dezvoltatorii și-au îmbunătățit abilitățile de a genera diverse tipuri de rapoarte care listează detalii de un fel sau altul. O întrebare care este postată din când în când în discuțiile online pe CompuServe, FoxForum.com sau Universal Thread este „Cum pot imprima mai multe seturi de linii de detalii?” Întrebarea se învârte de obicei în jurul detaliilor din două tabele diferite, fiecare având propriile date unice, dar trebuie amestecate împreună în același raport. Aceeași tehnică poate fi folosită pentru a rezolva problema cu două seturi de detalii într-un singur tabel.

Exemplul pe care îl vedem frecvent în raportarea noastră este necesitatea de a tipări rezumatul detaliilor pentru un grup de articole pentru perioada curentă de raportare, urmată direct de totalurile până la zi pentru fiecare dintre aceste elemente. În acest caz, detaliile sunt aceleași, dar elementele se repetă pentru fiecare grupare.

Așa cum am afirmat la începutul acestui capitol, lăsați Visual FoxPro să facă ceea ce face cel mai bine prin analizarea datelor. Pașii vor urma un model. Modelul va necesita un SQL-Select pentru fiecare set de înregistrări detaliate. Unul dintre câmpurile din SQL-Select va fi un tip de înregistrare care va distinge banda de detalii căreia îi aparține. Alegerea tipului de date și a valorii acestui câmp este importantă, deoarece este folosit pentru a determina ordinea benzii de detalii. Fiecare SQL-Select trebuie să aibă aceleași nume de câmp și dimensiune exactă, deoarece interogările vor fi îmbinate împreună cu clauza de unire după rularea interogărilor de bandă de detalii.

Exemplul prezentat în PeriodYtd.prg și enumerat în codul de mai jos răspunde la întrebarea „Care sunt vânzările de cărți de către fiecare grup de utilizatori pentru ultimul trimestru al anului 1999 și pentru întregul an?”

SELECTAȚI GrupUtilizator, ;

ySales AS ySalesReported, ;

"P" AS cPeriodOrYTD,;

dPeriodEnd ;

DE LA ch16sales ;

WHERE dPeriodEnd = {*1999-12-31} ;

INTO CURSOR curPeriod

SELECTARECUSERGROUP, ;

SUM(ySales) AS ySalesReported, ;

"Y" AS cPeriodOrYTD,;

{*1999-12-31} AS dPeriodEnd ;

DE LA ch16sales ;

WHERE dPeriodEnd => {*1999-01-01} ;

AND dPeriodEnd =< {*1999-12-31} ;

GROUP BY cUserGroup ;

ÎN CURSOR curYTD

SELECTAȚI * ;

FROM curPeriod ;

UNIRE ;

SELECTAȚI * ;

DE LA curYTD ;

COMANDA PENTRU 3, 1 ;

INTO CURSOR CUrReport

DACĂ _TALLY > 0

FORMULAR DE RAPORT PERIODYTD PREVIEW NOCONSOLE ACUM

ALTE

MESAGEBOX(„Fără date de raportat!”, 0+16, _screen.Caption)

ENDIF

Prima interogare primește vânzările din ultimul trimestru. A doua interogare reunește numerele până la zi pentru fiecare grup de utilizatori. SQL-Select final îmbină primele două interogări și sortează informațiile după tipul de înregistrare de detaliu (cPeriodOrYTD), urmat de numele grupului de utilizatori. Cursorul din exemplu are 4 rânduri de date care generează 4 linii de detalii pe raport.

Tabelul 16.1 Datele din cursorul numit curReport

cUserGroup 	ySalesReportedcPeriodOrYTDdPeriodEnd
Detroit Area Fox User Group 	750.0000P12/31/1999
Sterling Heights Computer Club 	50.0000P12/31/1999
Grupul de utilizatori Detroit Area Fox 	2450.0000Y12/31/1999
Sterling Heights Computer Club 	400.0000Y12/31/1999

Aspectul raportului este, de asemenea, important. Cheia succesului raportului este generarea unui grup pentru câmpul de tip de înregistrare de detaliu. Acesta este ceea ce generează mecanismul de repetare care emite diferitele linii de detalii.

Figura 16.11 Aspectul de raport cu mai multe detalii din Report Designer - observați că fiecare grup de detalii trebuie să aibă propria bandă de grup

Există multe variante ale acestei tehnici. Dacă combinați date diferite din tabele diferite, SQL-Selects devin puțin mai obositor de codat. Seturile de rezultate trebuie să se potrivească exact câmpul pentru câmp, atât ca dimensiune, cât și ca tip de date. Pentru a vă asigura că seturile de rezultate se potrivesc, poate fi necesar să efectuați conversii de date sau să inserați coloane în instrucțiunile dvs. SQL.

Cum să simulați o linie de detaliu mai lungă de o pagină (Exemplu:

DetBigPage.frx)

Există o limitare cu VFP Report Designer cu înălțimea benzii de raport. Înălțimea maximă a unei singure benzi este lungimea paginii (pe baza driverului de imprimantă cu care este proiectat sau pe care este imprimată). Aceasta înseamnă că nu puteți avea o bandă de detaliu pe o singură pagină. Deci, ce trebuie să facă un dezvoltator dacă datele dintr-o înregistrare sunt prea mari pentru a fi tipărite pe o singură pagină? Din fericire, există o soluție ușoară pentru această problemă.

Mai întâi trebuie să creați o grupare pe renoo în dialogul de grupare a rapoartelor (meniul Raport | Grupare date). Puteți selecta opțional gruparea pe Renoo pentru a începe pe o pagină nouă fără probleme. Dacă aveți alte grupări în raport, faceți ca gruparea de recunoaștere să fie grupul de cel mai înalt nivel (cel mai apropiat de Banda de detalii). Închideți dialogul de grupare pentru a reveni la Report Designer. Înălțimile benzilor pentru antetul paginii și subsolul trebuie setate mai întâi. Asigurați-vă că banda antetului paginii este setată pentru „Înălțimea benzii constantă”.

Cheia pentru a face acest truc să funcționeze este să utilizați cele trei benzi ca întreaga bandă de detalii. Cele trei benzi implicate sunt renoo Group Header, banda de detalii furnizată de VFP și renoo Group Footer. Fiecare dintre cele trei benzi poate avea înălțimea unei pagini întregi (mai puțin înălțimea antetului și subsolului paginii combinate). Aceasta înseamnă că detaliile pot fi prezentate în 3 pagini întregi în loc de o pagină limitată de Report Designer.

Există două opțiuni suplimentare disponibile. Dacă doriți un detaliu de două pagini, trebuie să măriți detaliul și fie renoo Group Header sau Group Footer. Cât de mare ai putea întreba? Banda de detalii ar trebui să fie cât de mare puteți încadra pe o pagină de hârtie, mai puțin înălțimile Antetului paginii și Subsolului paginii. Acesta va diferi în funcție de dimensiunea hârtiei și dacă imprimați în modul Portret sau Peisaj. Dacă doriți un detaliu de trei pagini, trebuie să extindeți atât Antetul grupului, cât și Subsolul, la înălțimea întregii pagini.

Există o situație în care acest truc nu va funcționa și este tipărirea câmpurilor de note care sunt setate să se întindă. O întindere a benzii de detalii va face ca raportul să depășească limita de o pagină pe o singură bandă (care este limitarea în jurul căreia funcționează acest truc).

În acest moment, sunteți gata să dispuneți câmpurile, etichetele și alte obiecte din raport. Toate câmpurile trebuie să aibă o dimensiune fixă. Niciunul dintre obiecte nu poate fi setat să plutească, deoarece întinderea nu este disponibilă. Va trebui să dimensionați câmpurile de text lungi care se așteaptă să fie încadrate în cuvinte pentru a avea o dimensiune fixă. Aceasta nu ar trebui să fie o problemă mare, deoarece acum aveți mai multe pagini cu care să lucrați pentru informații.

Cum se remediază locația subsolului (Exemplu: FixFooter.frx)

A fost întotdeauna obiectivul nostru să facem rapoartele să arate bine și să fie cât mai compacte posibil, dar din când în când ni se cere să imprimăm spațiu alb suplimentar. Această secțiune specifică tratează o solicitare pentru o dimensiune fixă a combinației antet, detaliu și subsol.

Situația este următoarea. Un utilizator dorește ca primii zece angajați ai fiecărui grup de vânzări să fie imprimați în ordinea de performanță a vânzărilor. Unele grupuri de vânzări pot avea 10 angajați de vânzări; alții pot avea mai puțin de 10 angajați. Șeful grupului de vânzări nu vrea să joace favorite și dorește aceeași cantitate de spațiu dedicat fiecăruia dintre grupurile din raport, indiferent de numărul de persoane din grup.

Această cerere unică necesită o gândire „în afara cutiei”. Mai întâi trebuie să creați o variabilă de raport. În exemplu, am numit această variabilă de raport nMaxRowsInGroup. Această variabilă este definită pentru a număra numărul de înregistrări prin opțiunea Calculare din grupare. Inițializați-l la zero, marcați-l pentru eliberare după raport și resetați-l la nivel de grup.

În subsolul grupului puneți un câmp cu următoarea expresie:

REPLICATE(CHR(13), <nFixedRows> - nMaxRowsInGroup)

Chr(13) este un retur de transport. Asigurați-vă că marcați întinderea cu depășire pentru acest câmp REPLICATE d.

Returul de transport adaugă o linie goală la câmpul extensibil. Expresia <nFixedRows> este

numărul maxim de rânduri pe care le veți imprima în banda de detalii. Exemplul de raport are o valoare codificată de 10. Nu trebuie să fie cazul. Puteți preprocesa cursorul selectat cu SQL-Select:

SELECTARE COUNT(cCategory) AS nCount ;

DIN chl6ug ;

GROUP BY cCategory ;

ÎN CURSOR curTemp

SELECTARE MAX (*) AS nFixedRows ;

DE LA curTemp ;

ÎN CURSOR curTemp2

În acest exemplu, ultima interogare vă oferă numărul maxim de rânduri pe care le veți procesa cu o grupare de rapoarte. Această valoare poate fi folosită ca parte a funcției REPLICATE() pentru a face rapoartele puțin mai dinamice.

Figura 16.12 Exemplul de raport de subsol fix este afișat în Report Designer. Cheia succesului remedierii poziției informațiilor din subsolul grupului este utilizarea funcției VFP REPLICATE() în subsolul grupului.

Cum se imprimă „Continuare” când detaliile depășesc (Exemplu:

WhiteSpace.frx/.prg)

Ați avut vreodată o solicitare de a tipări „Continuare...” pe subsolul unei pagini când antetul/detaliile grupului se imprimă pe o pagină și se termină pe pagina următoare? Dacă urmați direcția Microsoft cu articolul Q118560 din KnowledgeBase, veți urmări o vulpe în direcția greșită. Tehnica descrisă în articol nu funcționează în toate cazurile. De fapt, dintre tehnicile pe care le-am încercat peste

ani, a doua tehnică discutată în această secțiune nu este tocmai perfectă în ochii noștri, dar rezultatele sunt corecte.

Articolul Q118560 din KnowledgeBase, „Cum se indică continuarea înregistrării pe următoarea pagină a raportului” ar trebui să fie numit „Cum se imprimă rar, continuarea”. Acesta sugerează crearea unei variabile de raport pentru grup cu o valoare inițială de .f. și o valoare pentru stocare de .t., condiționând apoi tipărirea „Continuare...” în partea de jos a paginii dacă această variabilă este falsă. Ceea ce se întâmplă este că atunci când începe un nou grup, variabila este setată la .f., iar apoi setată la .t. când este tipărită următoarea înregistrare a grupului. Dacă următoarea înregistrare de după aceasta trece pe pagina următoare, „Continuare” nu este tipărită. Prin urmare, singura dată când „Continuare” este tipărit este atunci când antetul grupului este tipărit fără detalii pe aceeași pagină. Dacă acesta este ceea ce cauți, atunci ai cea mai simplă dintre cele două soluții.

Soluția mai bună necesită utilizarea unei variabile de memorie publică. În exemplul nostru, vom numi variabila glNewGroup. Înainte de a rula raportul, declarați variabila de memorie publică și inițializați-o la false. Variabila de memorie este manipulată în câteva funcții. Desigur, aceste funcții trebuie să fie în stiva de apeluri sau disponibile prin comanda SET PROCEDURE.

Variabila glNewGroup este setată la true de fiecare dată când un nou grup este întâlnit în raport. Apelând o funcție, GroupHeaderOnExit în exemplul nostru, din „Run Expression on Exit” din antetul grupului, face acest lucru. Variabila glNewGroup este apoi setată la false de fiecare dată când subsolul grupului este întâlnit prin apelarea unei alte funcții, GroupFooterOnExit în exemplul nostru, din subsolul grupului „Run Expression on Exit” . Ceea ce îi spune Report Designer-ului este că subsolul grupului a fost tipărit și antetul grupului nu a fost încă tipărit, prin urmare nu este nevoie să tipăriți mesajul „Continuare” în subsol. Iată exemple de proceduri necesare:

FUNCȚIE GroupHeaderOnExit

glNewGroup = .T.

RETURNARE .T.

FUNCȚIE GroupFooterOnExit

glNewGroup = .F.

RETURNARE .T.

Expresia Executare la ieșire nu permite ca atribuirea să fie efectuată direct. Acesta este motivul pentru care generăm funcțiile. Ultimul element necesar este mesajul din subsolul paginii. Expresia folosită în obiectul câmp poate fi ceva de genul următor cod:

IIF(glNewGroup,"Detalii continuate pe pagina următoare...",SPACE(0))

Acum raportul tipărește doar „Continuare” pe paginile care au linii de detalii încă de imprimat înainte de tipărirea subsolului grupului (chiar dacă este gol).
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Alte tehnici de raportare

Cum să evitați problemele cu imprimanta codificată greu

Rapoartele sunt uneori concepute într-un mod care obligă un dezvoltator să aleagă setări precum portret, peisaj, duplex sau alte setări specifice imprimantei. Adesea, alegerea se face pe baza numărului de câmpuri de date care trebuie tipărite în liniile de detalii. Unele alegeri sunt făcute în funcție de cerințele clienților. Aceste opțiuni pot fi salvate accidental în raport și pot cauza probleme cu imprimarea pe imprimantele clienților.

Orientarea imprimantei este determinată de setarea din dialogul Fișier|Configurare pagină din Visual FoxPro atunci când un raport este modificat. Apoi intrați în dialogul Print Setup pentru a selecta orientarea. Selectați orientarea pe care o cere raportul. Această setare va rămâne în raport cu raportul, indiferent de setarea de orientare pentru acea imprimantă (fie în Windows, fie în imprimanta implicită VFP setată printr-un sys<io37>). Cheia este să lăsați imprimanta implicită Windows selectată înainte de a face selectarea orientării. Dacă este selectată o altă imprimantă, VFP va lega setarea imprimantei de raport

Există unele preocupări cu dialogul Configurare imprimantă care trebuie urmărite. Se poate avea probleme în următorul scenariu.

Să presupunem că ați urmat toți pașii noștri descriși mai sus și totul a funcționat excelent. Acum apelați sys(io37) și alegeți o altă imprimantă care este diferită de imprimanta implicită Windows. Acum modificați raportul, nu faceți nicio modificare, ci doar apăsați CTRL+W pentru a salva raportul. Visual FoxPro tocmai a salvat informațiile despre o anumită imprimantă de dezvoltare în raportul dvs., suprascriind setările originale pentru „imprimantă implicită”. Acum, raportul se va tipări pe imprimanta respectivă sau va folosi atributele asociate cu acea imprimantă la imprimarea raportului la imprimanta clientului. Diferența dintre imprimante poate fi subtilă sau semnificativă. Dacă imprimanta de dezvoltare acceptă duplexarea și imprimanta clientului nu, instrucțiunile pentru imprimare ar putea avea efecte negative.

Acesta este motivul pentru care ar trebui întotdeauna MODIFICARE RAPORT în timp ce SYS(1037) (sau File|Page Setup) este setat la imprimanta implicită. Consultați capitolul despre ProjectHooks pentru a vedea o tehnică care va curăța aceste informații codificate greu din fișierele FRX.

Cum să utilizați Expression Builder pentru câmpurile cursorului nedefinite în DataEnvironment al raportului

Aparent, Expression Builder a devenit mai inteligent atunci când este utilizat cu Report Designer între FoxPro 2.6 și Visual FoxPro. S-a dovedit în repetate rânduri că mai inteligent nu este întotdeauna mai bun. În cele 2,6 zile, Generatorul de expresii ar afișa toate câmpurile din toate tabelele deschise. VFP

Expression Builder afișează numai câmpurile pentru tabelele incluse în mediul de date al raportului. Mulți dezvoltatori nu folosesc mediul de date, dar folosesc Expression Builder.

Figura 16.13 Generatorul de expresii cu tabelul Order din câmpurile bazei de date TasTrade împrăștiate în memvars

VFP Expression Builder (a se vedea Figura 16.13) este accesat prin dialogul Report Expression. Afișează câmpurile tabelului în partea stângă a casetei de dialog și variabilele definite în partea dreaptă a dialogului. Metoda de a completa partea variabilelor este pur și simplu să deschideți tabelul sau vizualizarea sau să rulați un cod SQL-Select pentru a construi un cursor, apoi să faceți din acesta zona de lucru activă. Executați următorul cod în fereastra de comandă VFP:

SCATTER MEMVAR MEMO

Variabilele create sunt afișate în caseta de listă din colțul din dreapta jos al Generatorului de expresii. Puteți utiliza aceste variabile în expresie la fel ca și câmpurile dintr-un tabel făcând dublu clic pe variabila de memorie sau prin tabularea în listă și selectând variabila dorită. Unul dintre avantajele secundare ale acestei tehnici este că aliasul tabelului nu este inclus în expresie, așa cum este atunci când selectați un câmp din dialog. Codarea tare a aliasului din expresie face ca raportul să fie inflexibil atunci când ar putea fi folosit cu mai multe cursoare diferite.
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Cum să faceți ca formatele de etichete să fie disponibile

Una dintre întrebările frecvente puse de dezvoltatorii VFP la prima dată când creează etichete este cum pot preîncărca diferitele formate standard de etichete disponibile pe piață? Există mai mult de 80 de aspecte Avery® diferite acceptate nativ în Visual FoxPro.

Diferitele formate de etichete Avery sunt stocate în registru (vezi Figura 16.15). Dacă doriți să fie încărcate machetele, cel mai simplu mod este să rulați VFP Label Wizard. Este una dintre rarele momente în care recomandăm să rulați Visual FoxPro Wizards. Consultați Figura 16.14 pentru mesajul care este afișat la prima rulare a expertului.

Figura 16.14 Prima dată când rulați Label Wizard vi se va afișa o fereastră de mesaj care vă spune că va adăuga formatele standard de etichete Avery la cele disponibile în VFP

De asemenea, puteți adăuga formatele în registry făcând dublu clic pe fișierul Labels.reg din directorul HOME()+"Toois\Ad<n.abei\" din Window's Explorer. Aceasta rulează Editorul Registrului și încarcă setările în Registry. Acesta este același mod în care Label Wizard încarcă Registry.

Figura 16.15 Formatele de etichetă Avery sunt stocate în Registrul Windows
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Raportați manipularea metadatelor

Codul sursă al raportului Visual FoxPro este stocat în tabele libere VFP obișnuite cu extensiile FRX/FRT. Deoarece toți manipulăm datele pentru a ne trăi (ei bine, cei mai mulți dintre noi o fac), este firesc să dorim să piratam fișierele de metadate. Cheia pentru a „încurca cu codul” este să efectuați aceste operațiuni numai pe copii de rezervă. Nu rulați niciodată un instrument de hacker de cod pe singura copie a oricărui tabel de raport (sau oricare dintre celelalte tabele de metadate). Nu este nevoie de foarte mult pentru a dezactiva Report Designer de la deschiderea unui raport. Odată ce înțelegeți această putere și flexibilitate, precum și aspectul fișierului de raport, puteți utiliza aceste cunoștințe pentru a construi instrumente care vă ușurează experiența de dezvoltare.

Cum schimbi fonturile în mod programatic? (Exemplu: ChgFont.prg)

Aplicațiile sunt distribuite clienților care au o varietate de gusturi. Unul dintre elementele pe care clienții le plac cel mai mult, personalizate după gusturile lor este aspectul și fonturile pentru rapoarte. Deși dezvoltatorii își pot câștiga existența schimbând și ajustând rapoartele, de multe ori există puțin timp pentru a gestiona acest aspect al sarcinilor noastre și aceste schimbări devin adesea o prioritate mai scăzută.

Problema cu Report Designer atunci când vine vorba de schimbarea fonturilor este că trebuie să alegeți nu numai fontul, ci și dimensiunea și dacă este aldin sau cursiv pentru obiectul raportului. Aceasta înseamnă că trebuie să selectați obiecte care au exact aceleași atribute de font, altfel toate devin la fel. Acesta este un proces foarte obositor pentru rapoartele care au o mulțime de dimensiuni și stiluri de font diferite. Dacă ar exista o modalitate de a accelera procesul?

Caracteristicile raportului sunt stocate în format tabel. FontName este stocat în coloana FontFace a acestui tabel. Soluția este să scanați tabelul și să înlocuiți valoarea coloanei cu un nou FontName. Iată codul de bază al programului ChgFont:

UTILIZAȚI (tcReportMetadata) EXCLUSIV ÎN 0 ALIAS curFontChanger

SELECTează curFontChanger

SCANĂ

IF !EMPTY(FontFace)

ÎNLOCUIȚI FontFace CU tcFontName ÎN curFontChanger

ENDIF

ENDSCAN

UTILIZAȚI ÎN curFontChanger

Există și alte situații, cum ar fi mai multe fonturi utilizate în același raport și este posibil să doriți să le modificați doar pe unele specifice, de exemplu:

ÎNLOCUIȚI TOATE FontFace CU „Arial” PENTRU FontSize = 10

Există un pericol cu acest proces de care trebuie să fii conștient. Fonturile diferite au valori diferite ale fonturilor. Acest lucru înseamnă că diferitele fonturi au înălțimi, lățimi, forme, dimensiuni și stiluri diferite. Acest lucru poate avea efecte secundare negative dacă nu este utilizat în mod corespunzător. Dacă utilizați un font simplu de dimensiune fixă, cum ar fi Courier New, și decideți să schimbați la ceva precum Goudy Stout, obiectele dvs. de etichetă pot primi

trunchiat deoarece Visual FoxPro stochează lățimea pixelilor obiectelor text. Dimensiunile din designerii de dezvoltare nu reflectă ceea ce obțineți atunci când rulați raportul cu o comandă REPORT FORM. Dacă un font specificat într-un raport nu este încărcat pe computerul utilizatorului, Windows va înlocui unul care consideră că reprezintă îndeaproape aceleași atribute ca și fontul pe care l-ați specificat. Windows nu este întotdeauna bun la acest lucru și raportul se poate imprima diferit de proiectat. Pe de altă parte, dacă treceți la fonturi cu valori similare pentru fonturi, veți economisi mult timp și efort, mulțumind clientul.

Cum se convertesc dimensiunile hârtiei (Letter -> A4 Print) (Exemplu: Letter2A4.prg)

Dezvoltatorii care au clienți cu mai mult de un standard de dimensiune de hârtie, cum ar fi 8,5 x 11 și A4, vor aprecia această secțiune. Am dat peste un program care convertește tipurile de hârtie pentru toate rapoartele într-un singur director. Pentru cei care nu o fac, vă va oferi mai multe informații despre curajul metadatelor raportului. Dezvoltatorii care lucrează în mod nativ în lumea A4 și au clienți care lucrează cu hârtie de dimensiunea litere pot face cu ușurință ingineria inversă a procesului pentru nevoile lor.

Lista 16.1 Acest cod convertește un raport de la dimensiunea de hârtie Letter la A4

LOCAL IcOldSelect && Salvează zona de lucru curentă

LOCAL lnCounter && FOR contor de bucle

LOCAL laFRX && Matrice de rapoarte

lcOldSelect = SELECT ()

SELECTARE 0

=ADIR( laFRX, '*.FRX')

PENTRU lnCounter = 1 LA ALEN(laFRX, 1) PASUL 1

UTILIZAȚI (laFRX[lnCounter, 1]) ÎN 0 EXCLUSIV

* Schimbați setarea din prima înregistrare de la Letter la A4

ÎNLOCUITĂ Expr CU SUBSTR(Expr, 1, AT("PAPERSIZE", Expr) - 2) + ;

"PAPERSIZE=9" +;

SUBSTR( Expr, AT ("PAPERSIZE", Expr) + 12), ;

Latime CU 77433.000

LOCATE FOR TRIM(Expr) = „DATA()”

DACA ESTE GASIT()

ÎNLOCUIȚI HPos CU 1562.5, Lățime CU 8854.167

ENDIF

LOCATE FOR TRIM(Expr) = '"Pagină"'

DACA ESTE GASIT()

ÎNLOCUIȚI HPos CU 66250.000

ENDIF

LOCATE FOR TRIM(Expr) = „_PAGENO”

DACA ESTE GASIT()

ÎNLOCUIȚI HPos CU 70416.667

ENDIF

UTILIZARE

ENDFOR

SELECTARE (IcOldSelect)

ÎNTOARCERE
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Concluzie

Raportarea poate fi distractivă doar din cauza provocărilor cu care ne confruntăm în limitările Visual FoxPro Report Designer. Ne gândim întotdeauna că clienții plătitori vor prezenta încă un raport de care au nevoie, care la început pare a fi imposibil în aceste limite. În realitate, au existat foarte puține rapoarte pe care nu le-am putut realiza folosind instrumentele pe care ni le oferă VFP. În capitolul următor vom discuta câteva elemente suplimentare în gestionarea procesului de raportare.
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Capitolul 17 - Gestionarea rapoartelor

„Raportați-mă și cauza mea corect”. ("Hamlet" de William Shakespeare)

Utilizarea Visual FoxPro Report Designer este doar jumătate din luptă atunci când se generează rapoarte pentru utilizatorii unei aplicații. În timp ce lupta cu Report Designer poate fi o provocare, există cealaltă jumătate a acestui proces, care este gestionarea creării, prezentării și ieșirii raportului. Acest capitol acoperă o serie de sfaturi despre lustruirea rezultatelor, lucrul cu modul de previzualizare a raportului, depanare și câteva alternative de raportare folosind capabilități native VFP și automatizare.

În capitolul anterior am acoperit câteva sfaturi și tehnici de lucru direct cu Raportul

Designer. Acest capitol are un accent ușor diferit, deoarece majoritatea discuțiilor se concentrează pe raport

Comanda FORM sau mecanisme alternative.
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Cum să folosiți rapoarte și sesiuni de date

Visual FoxPro raportează implicit la sesiunea de date curentă. Rapoartele sunt, de asemenea, capabile să ruleze în propriile sesiuni de date private, la fel ca și formularele. Deși la început pare o funcție intrigantă de utilizat, ne trezim că le folosim rar (consultați secțiunea „Cum să previzualizați mai multe rapoarte simultan”).

Motivul principal pentru care nu folosim sesiunea de date privată a raportului este că folosim, în general, codul SQL-Select pentru a pregăti datele pentru raport. Dacă folosim un raport cu o sesiune de date privată, trebuie să codificăm cursoarele în mediul de date sau trebuie să scriem cod special pentru raport în metodele mediului de date. În opinia noastră, ambele scenarii au dezavantaje, deoarece codul este utilizabil numai în raportul în care este definit. Raportul devine inflexibil, deoarece poate fi folosit doar cu cursoarele statice. Rapoartele cu medii de date hard-coded au puțină flexibilitate în afară de capacitatea de a folosi vizualizări parametrizate.

Procesul alternativ pe care îl folosim este de a configura cursoarele de raport într-un formular cu o sesiune de date privată. Codul SQL pe care îl folosim este de obicei generat dintr-un număr de criterii definite de utilizator. Criteriile utilizator sunt introduse prin interfața formularului. Pe baza combinației de selecții introduse de utilizator, construim dinamic SQL-Select-urile și generăm cursorul(ele) finale care sunt utilizate în raport. Deoarece avem deja un formular pentru a permite utilizatorului introducerea criteriilor, de ce să nu profitați de sesiunea de date privată a formularului? Codul care poate fi generat (prin substituții de macro) este mult mai ușor de lucrat sub formă decât ar fi într-o metodă de mediu de date de raport.

Deoarece raportul folosește sesiunea de date implicită (care înseamnă într-adevăr sesiunea de date curentă, nu sesiunea de date 1), putem defini datele în mod specific pentru un raport printr-un formular de criterii de raport personalizat sau putem folosi sesiunea de date a altui formular (cum ar fi un formular de introducere a datelor ) dacă cerințele o cer. Această abordare oferă o flexibilitate completă.
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Cum se creează un șablon de raport pentru un proiect (Exemplu:

Untitled.frx)

Una dintre plângerile comune despre Visual FoxPro este lipsa rapoartelor orientate pe obiecte. Ar fi grozav să definim un raport și ca caracteristicile de bază să fie moștenite la fel ca și clasele, dar trebuie să ne mulțumim cu o altă tehnică de modă veche de a avea un șablon de raport. Tehnica descrisă este bună prin faptul că putem folosi un comportament implicit al Visual FoxPro.

Ce se întâmplă când executați următorul cod în fereastra de comandă?

CREAȚI RAPORT

Un nou raport este deschis în VFP Report Designer. În acest moment raportul nu este numit. (Apare ca Raport N, unde N este numărul de secvență al raportului creat pentru acea sesiune VFP.) Puteți efectua doar o Salvare ca din meniu, nu o Salvare în numele fișierului curent. Ce se întâmplă când executați următorul cod în fereastra de comandă?

CREATE RAPORT fără titlu

Exact același lucru - un nou raport fără nume este deschis în VFP Report Designer și poate fi salvat numai cu Salvare ca. Deci ce se întâmplă aici? S-ar putea să vă întrebați și de ce ar dori cineva să adauge „untitled” inutil la linia de comandă? Cheia aici este să folosiți acest comportament nativ al Visual FoxPro. Mai întâi creați un nou raport și salvați-l cu numele „untitled.frx”. Acum, când VFP este rugat să creeze un nou raport cu comanda CREATE REPORT untitled, va deschide șablonul „untitled.frx” în Report Designer, atâta timp cât poate fi găsit.

Deci, cum putem profita de acest comportament? Primul pas este crearea șablonului de raport. Fiecare proiect poate diferi, dar creați elementele de bază ale raportului astfel încât să îndeplinească cerințele clientului. În exemplul capitolului „untitled.frx” includem numele sistemului și numărul paginii în antet, data în subsol, o grupare pe eofo și setăm fontul implicit pentru raport la Tahoma. Într-un mediu de producție (sau sistem) câmpuri generice pot fi create pentru lucruri precum numele aplicației, echivalentul în limbaj natural al criteriilor de selecție, data, ora, numerele de pagină, numele raportului sau o grupare pe eofo . Puteți dimensiona anteturile, subsolurile, puteți include pagini de titlu implicite și orice altceva pe care inima dvs. dorește sau pe care clientul le cere.

O altă tehnică pe care o folosim tot timpul este includerea „untitled.frx” într-un proiect. Salvăm șablonul în directorul raportului de proiect. Acesta devine șablonul pentru întregul proiect. Când avem de dezvoltat un nou raport, doar modificăm raportul „fără titlu” de la Managerul de Proiect. Acest lucru permite echipelor de dezvoltare să partajeze șablonul comun pentru proiect și să aibă șabloane separate pentru clienți diferiți sau chiar proiecte diferite pentru același client. Excludem raportul „fără titlu” din Managerul de proiect, așa că nu este inclus în niciun executabil lansat. Este un raport pe care clienții nu l-ar rula niciodată, așa că nu este nevoie să-l elibereze.

Un alt punct care merită discutat este îmbunătățirea sau modificarea șablonului. Deoarece comportamentul implicit al Visual FoxPro este de a salva noul raport cu un alt nume, va trebui întotdeauna să salvați ca „untitled.frx”. Deoarece construim rapoarte dintr-un șablon static în loc de o clasă dinamică, orice modificări aduse șablonului nu sunt propagate în rapoartele existente care au fost create cu șabloanele.
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Cum se imprimă o serie de pagini (Exemplu Range.scx)

Imprimarea intervalelor de pagini în VFP Report Designer pare un sfat evident, dar este unul pe care îl ajutăm frecvent pe alți dezvoltatori să descopere, așa că am decis să îl includem în acest capitol. Clauza de interval din comanda REPORT FORM permite dezvoltatorilor (și utilizatorilor) să specifice paginile pe care doresc să le iasă pe imprimantă, pe ecranul desktop VFP sau într-un fișier.

Următorul exemplu de cod oferă o privire asupra unei metode de valorificare a acestei caracteristici într-o aplicație:

FORMULAR DE RAPORT (lcReportName) PENTRU IMPRIMANTE NOCONSOLE ;

INTERVAL (THISFORM.txtStartPage.Value), (THISFORM.txtEndPage.Value)

Intervalul este ignorat dacă raportul este previzualizat. Intervalul de început nu poate fi mai mic de 1, dar sfârşitul intervalului poate fi mai mare decât numărul de pagini din raport. Dacă intervalul dvs. de început este mai mare decât numărul de pagini, veți primi o coală goală de hârtie.

După cum arată codul exemplu, cheia este de a permite intrarea intervalului de pagini pentru raport. Adăugați câteva casete de text sau comenzi rotative într-un formular pentru a oferi utilizatorilor un interval de intrare. Asigurați-vă că câmpurile sunt implicit 1 pentru pagina de pornire și ceva ridicol de mare, cum ar fi 999, pentru a vă asigura că toate paginile sunt tipărite dacă nu ating selectați intervalul. Aceasta este o caracteristică perfectă de adăugat la formularul de bază pentru criteriile de raportare.
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Cum se imprimă „Pagina x din y” pe un raport (Exemplu PageXofY.frx/scx)

Una dintre întrebările mai frecvente puse de dezvoltatorii Visual FoxPro este cum să obțineți numărul de pagini din raport, astfel încât să poată imprima Pagina xx din yy pe raport. Multe pachete software centrate pe documente, cum ar fi procesoarele de text, au reușit să facă acest lucru de ani de zile. Multe alte produse Microsoft, cum ar fi suita Office, au aceste capabilități, așa că de ce nu Visual FoxPro? Ei bine, încă o dată, există un proces prin care ne putem rula rapoartele pentru a obține acest răspuns.

Visual FoxPro stochează numărul curent al paginii într-o variabilă de sistem numită _pageNo. La sfârșitul raportului, numărul de pagini este stocat în această variabilă. Cea mai comună soluție propusă pentru această problemă este să rulați raportul de două ori, mai întâi:

PRIVAT pnTotalReportPages

pnTotalReportPages = 0

REPORT FORM <ReportFormName> NOCONSOLE

pnTotalReportPages = _PageNo

Sfera de aplicare a variabilei de memorie (pnTotalReportPages în exemplu) ar trebui să fie privată, deoarece va fi utilizată în afara metodei/procedurii în care este declarată atunci când este creat raportul. Nu uitați să inițializați variabila de memorie privată care va conține numărul de pagini înainte de a rula raportul pentru faza de contor de pagini. În caz contrar, ați putea avea probleme cu raportul care nu rulează, deoarece această variabilă este probabil utilizată în raport. În acest moment, variabila de memorie pnTotalReportPages conține numărul de pagini și o puteți utiliza a doua oară când rulați raportul.

fBgeAW.Îz 	Contacte SystemPagelof3

Dezvoltat ca exemplu pentru cartea excelentă

1001 de lucruri pe care ai vrut să le știi despre Visual FoxPro

Id de contact Nume 	Companie

1 	Prăjitor de cafea DavoliOj NancyCascade

Figura 17.1 Exemplul de titlu a raportului arată Pagina x din y în colțul din dreapta sus.

Iată un exemplu de numere de pagină care sunt tipărite pe raport. Vă permite să previzualizați raportul în modul design fără a fi nevoie să configurați în prealabil variabila totală de pagini.

„Pagină” + ALLTRIM(STR(_PAGENO)) + ;

IIF(TYPE("pnTotalReportPages")="N"," din "+ALLTRIM(STR(pnTotalReportPages)),"")

Ca alternativă, următorul rând de cod este folosit de mulți dezvoltatori VFP pentru a determina numărul de pagini dintr-un raport.:

REPORT FORM <ReportFormName> NOCONSOLE TO NUL

Cel mai mare dezavantaj al tehnicii Page xx of yy este că raportul rulează de fapt de două ori, ceea ce poate consuma mult timp pentru rapoarte mai lungi. Dialogul de tipărire a raportului VFP este, de asemenea, afișat de două ori la imprimarea către imprimantă, o dată pentru faza de numărare și o dată pentru ieșirea efectivă a raportului. La previzualizarea unui raport, dialogul este afișat o dată pentru faza de numărare. Din experiența noastră, utilizatorii finali consideră că performanța depășește beneficiile de a avea aceste informații, dar tehnica funcționează bine pentru cei care văd acest lucru ca fiind un lucru obligatoriu.
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Cum le permiteți utilizatorilor să selecteze numărul de copii (Exemplu

PageXofï.frx/scx)

Utilizatorii aplicației adoră să genereze rapoarte și le place să le distribuie diferiților lor colegi și șefi. Astfel, cerința de tipărire a unui număr specificat de copii este o solicitare frecventă de dezvoltare a sistemului care necesită dezvoltarea unei soluții generice.

Soluția este o buclă simplă în jurul unui formular de raport, deoarece nu există o clauză încorporată pentru FORMULARUL DE RAPORT.

Trebuie creată o interfață care să sprijine un utilizator să selecteze numărul de copii, cu excepția cazului în care există o cerință specifică ca să fie generat un număr fix de copii.

Figura 17.2 Exemplul de formular care permite utilizatorilor să introducă între 1 și 999 de copii ale unui raport către imprimantă

Exemplul de cod pentru a gestiona această tehnică se găsește în butonul de comandă Run Report. Ieșirea previzualizării necesită o singură iterație prin generarea raportului. Bănuim că ar putea fi declanșat o interfață ostilă pentru utilizator pentru a-l face pe utilizator să previzualizeze numărul de copii pe care le selectează. De asemenea, sugerăm câteva întrebări adecvate dacă vor fi făcute mai mult de 20 de copii, deoarece credem că destui copaci din pădurea tropicală din America de Sud au suferit o moarte prematură:

IF THISFORM.opgOutput.Value = „Previzualizare”

InNumberOfCopies = 1

IcOutput = „Previzualizare”

ALTE

InNumberOfCopies = THISFORM.spnCopies.Value

IcOutput = „LA IMPRIMANTE”

ENDIF

FOR lnCount = 1 TO InNumberOfCopies

FORMULAR DE RAPORT (lcReportName) &lcOutput NOCONSOLE

ENDFOR

Exemplul de control spinner este locul în care setările proprietăților trebuie să restricționeze numărul de copii de la mai puțin de 1 și mai mare de 999.

O altă opțiune pentru a gestiona mai multe copii este utilizarea clauzei prompt din comanda REPORT FORM, permițând utilizatorului final să selecteze un număr de copii dacă driverul de imprimantă acceptă această opțiune. Avem

am stat departe de clauza promptă, deoarece utilizatorii noștri nu au dorit ca dialogul suplimentar să fie afișat după formularul tipic de introducere a criteriilor de raport în aplicațiile noastre. Această metodă de selectare a numărului de copii predă controlul driverului de imprimare Windows pentru a valorifica capacitatea imprimantei de a imprima copii fără a rula raportul de mai multe ori. Acesta este un mod mai eficient de a obține mai mult de o copie la o imprimantă.
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Cum să găsiți erorile „Variabilă negăsită” într-un raport

Dezvoltatorii VFP care au folosit Report Designer la un moment dat s-au confruntat cu mesajul de eroare „Variabilă <variabilă> negăsită” în timp ce testau cel mai recent executabil al aplicației. Acest mesaj este agravant, deoarece este afișat fără a vă spune unde este greșită expresia din raport. Această expresie este uneori dificil de găsit, deoarece ar putea exista zeci de câmpuri în raport. Pentru a agrava această problemă, eșecul expresiei ar putea fi în calculul câmpurilor, calculul variabilelor de raport sau condițiile Print When. Ați găsit vreodată o expresie proastă în raportul altcuiva în Imprimați când a unui obiect linie? Condiție. Crede-ne, nu este prea distractiv.

Din fericire, există o tehnică care accelerează urmărirea acestor bug-uri dureroase. Cheia pentru o rezoluție rapidă este suspendarea codului programului după ce cursoarele finale sunt pregătite. Dacă acest lucru nu este practic, pregătiți datele manual. Odată ce datele sunt pregătite, modificați raportul și previzualizați-l. Eroarea va fi afișată. După ce închideți modul de previzualizare a raportului, Report Designer va afișa câmpul de expresie în care apare eroarea. În acest moment, puteți face corectarea, salvați raportul și încercați din nou. Repetați până când toate bug-urile sunt eradicate.
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Cum să evitați să aveți un raport dezactivați meniul de sistem

S-a închis vreodată o previzualizare a raportului și meniul este dezactivat? A existat o eroare în VFP 5.0 despre care nu suntem siguri că este remediată în cea mai recentă versiune de VFP. Acesta este unul dintre acele erori dureroase, intermitente și greu de reprodus, care nu se întâmplă cu toate rapoartele. Soluția nu este dureroasă, așa că merită menționată în acest moment.

Pașii care au fost comuni pentru dezactivarea meniului de sistem sunt următorii:

1. 	Rulați un formular pentru un raport care conține criteriile de selecție.

2. 	Previzualizați raportul necesar (prin intermediul unui buton de comandă).

3. 	Închideți raportul utilizând butonul de închidere a ferestrei de previzualizare din colțul din dreapta sus.

4. 	Închideți formularul de criterii de raportare.

În acest moment, toate elementele de meniu sunt dezactivate la fel cum rulează un formular modal. Dacă utilizatorul iese din modul de previzualizare a raportului folosind tasta de evacuare sau butonul de comandă de ieșire din bara de instrumente de previzualizare, elementele de meniu nu sunt dezactivate. Soluția este de a încheia comanda REPORT FORM cu un MENIU PUSH și

MENIU POP.

PUSH MENU _msysmenu

FORMULAR DE RAPORT <ReportName> PREVIEW. . .

MENIU POP _msysmenu

Meniul push și pop are unele cerințe semnificative de memorie, dar puterea mașinii necesară pentru a rula aplicațiile bazate pe VFP 6.0 poate face față cu ușurință la acest lucru.
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Cum să adunați pagini din diferite rapoarte

Există momente când mai multe aspecte de raport complet diferite trebuie adunate sau ordonate în rezultat. Am avut clienți care au documente legale care sunt tipărite în mod regulat pe hârtie complet diferită, dar sunt considerate parte a unui pachet. Cum se poate face ca Report Designer să imprime rapoarte diferite pe diferite pagini de tipărire sau cu machete complet diferite care să fie adunate împreună?

Soluția pe care am conceput-o a scos o gândire din cutie. Proiectarea de bază constă în utilizarea unui formular de selecție a criteriilor raportului de conducere. Acest formular are toate obiectele de interfață selectabile de utilizator pentru a determina setul de înregistrări de bază. Acest formular „conduce” rapoartele să fie tipărite în ordine.

Odată ce utilizatorul face selecția criteriilor, obiectul raportului intră în acțiune. Secvența poate fi modelată în următorii pași:

1. 	Se execută interogări pentru a obține setul de înregistrări care se potrivește cu selecțiile utilizatorului.

2. 	Porniți bucla prin rezultatul interogării inițiale.

3. 	Subinterogarea pentru raportul unu este făcută pentru a obține una sau mai multe înregistrări pentru raport pe baza interogării inițiale

4. 	FORMULAR DE RAPORT <raport 1>.

5. 	Subinterogarea pentru raportul doi se face pentru a obține una sau mai multe înregistrări pentru raport pe baza interogării inițiale.

6. 	FORMULAR DE RAPORT <raport 2>.

7. 	Continuați să repetați prin toate rapoartele.

8. 	Buclă la pasul 3 până când toate înregistrările sunt procesate.

Figura 17.3 Aceasta este arhitectura utilizată pentru a apela diferite rapoarte în secvență atunci când împachetați și colaționați diferite aspecte ale rapoartelor

La început, designul pare că este cel mai potrivit pentru rapoartele care nu imprimă numere de pagină, deoarece fiecare raport va inițializa variabila _pageno la 1 atunci când raportul este tipărit. Există o modalitate de a evita această limitare prin crearea unei variabile private care ține evidența paginilor de raport tipărite. Inițializați variabila de memorie la 0 și, după fiecare raport, adăugați valoarea lui _pageno. În rapoartele noastre, folosim de obicei următoarea expresie pentru a tipări numărul paginii pe raport:

" Pagina " +ALLTRIM ( STR (_PAGENO) )

În situația de aspect cu mai multe rapoarte, trebuie să adăugăm variabila memorie privată la numărul de pagini din raportul curent:

„Pagină” + ALLTRIM (STR(_PAGENO + ;

IIF(TYPE("pnAllPrevPages") = "N", pnAllPrevPages, 0)))

Vă recomandăm să verificați tipul variabilei de memorie privată, astfel încât să puteți rula raportul autonom (fără formularul de apelare). Dacă raportul este rulat cu procesul de colare, variabila va fi deja definită și raportul va rula bine. Dacă doar testați raportul singur (de exemplu, previzualizarea din Report Designer), verificarea tipului de variabilă va evita o eroare „Variabilă negăsită”. Majoritatea rapoartelor nu necesită mai multe machete, dar dacă apare situația în care aveți nevoie de ele, cel puțin veți avea un punct de plecare pentru a începe.
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Cum să afișați un „Dialog de imprimare* personalizat (Exemplu Contacts.frx,

ChangePrinting Window.prg)

De-a lungul anilor, mulți dezvoltatori au întrebat despre modificarea casetei de dialog „Printing...” afișate atunci când un raport este trimis la o imprimantă. Unul dintre motivele pentru care mulți dezvoltatori le place să ofere propriul dialog este că dialogul VFP notează numele raportului care este tipărit. Figura 17.4 prezintă un exemplu al acestui dialog. „timelistd.frx” are vreo semnificație pentru un utilizator final? Acești dezvoltatori le place să aibă mai mult control asupra afișajului. Se poate face? Desigur, altfel de ce am tipări o secțiune din capitol?

Figura 17.4 Dialogul de imprimare VFP

Consultați mai întâi programul ChangePrintingWindow.prg disponibil cu fișierele de descărcare pentru dezvoltatori ale capitolului, disponibile la www.hentzenwerke.com. Codul programului poate fi găsit în Lista 17.1

Lista 17.1 Acest cod afișează un dialog personalizat de imprimare

LPARAMETER tcTitle, telcon, tcText

* 	Numele ferestrei VFP a ferestrei de imprimare implicită

#DEFINE ccWIN_PRlNTING „Se imprimă...”

* 	Definiți variabilele locale

IcFont LOCAL

LOCAL InSize

IcStyle LOCAL

LOCAL InTitle

LOCAL InLeftBorder

LOCAL InTopBorder

LOCAL InInaltime

LOCAL InWidth

* 	Schimbați fereastra doar dacă există

IF WEXIST(CCWIN_PRINTING)

DACĂ EMPTY(WPARENT(ccWIN_PRINTING))

IcFont = WFONT( 1, CCWIN_PRINTING )

InSize = WFONT( 2, CCWIN_PRINTING )

IcStyle = WFONT( 3, ccWIN_PRINTING )

InHeight = FONTMETRIC(6, lcFont, lnSize, IcStyle)

lnWidth = FONTMETRIC(4, lcFont, lnSize, lcStyle) + ;

FONTMETRIC(1, lcFont, lnSize, lcStyle) lnLeftBorder = SYSMETRIC(3) / lnHeight lnTitle = (SYSMETRIC(9)+2) / lnWidth lnTopBorder = SYSMETRIC(4) / lnWidth DEFINE WINDOW CustomPrint;

DIN WLROW(ccWIN_PRINTING), WLCOL(ccWIN_PRINTING) ;

SIZE WROWS(ccWIN_PRINTING) - lnTopBorder, ;

WCOLS(ccWIN_PRINTING) - lnLeftBorder ;

SISTEM ;

TITLE tcTitle ;

MINIMIZAȚI ZOOM FLOTĂ ÎNCHIS;

FIȘIER ICONA (tcIcon) ;

FONT lcFont, lnSize;

STYLE lcStyle ;

CULOARE RGB(0, 0, 0, 192, 192, 192)

DEFINEREA FEREASTRA CustomPrintReport ;

DE LA 0, 0;

TO (WROWS(ccWIN_PRINTING) - lnTopBorder) / 3, ;

WCOLS(ccWIN_PRINTING) - lnLeftBorder ;

NICI UNUL ;

FONT lcFont, lnSize;

STYLE lcStyle ;

CULOARE RGB(0, 0, 0, 192, 192, 192) ;

ÎN FEREASTRĂ CustomPrint

ACTIVAȚI FEREASTRA CustomPrint

ACTIVAȚI FEREASTRA ccWIN_PRINTING ÎN CustomPrint

MOVE WINDOW ccWIN_PRINTING TO - (lnTopBorder + lnTitle), - lnLeftBorder

ACTIVAȚI FEREASTRA CustomPrintReport

@ 1, 1 SAY PADC(tcText, WCOLS(„CustomPrintReport”))

ENDIF

ENDIF

ÎNTOARCERE ""

Codul este simplu dacă ați dezvoltat în FoxPro 2.x. Pentru acei dezvoltatori FoxPro care au început cu generația VFP, codul poate să nu fie simplu. Programul ia trei parametri. Primul este titlul formularului, urmat de pictograma formularului și, în final, un mesaj care urmează să fie afișat în dialog. Folosind comanda DEFINE WINDOW, putem crea în memorie un formular vechi în stil FoxPro 2.x. Comanda ACTIVATE WINDOW face apoi vizibilă fereastra nou definită și îi dă focus. Comanda MOVE WINDOW preia dialogul VFP existent și îl mută de pe ecranul vizibil, astfel încât noul dialog personalizat este văzut și este singurul dialog de imprimare vizibil. @ 1, 1 SAY afișează textul definit pe acea linie la rândul unu și coloana unu din formularul respectiv.

Metoda de afișare a dialogului personalizat necesită un apel direct dintr-un câmp de raport la procedura ChangePrintingWindow. Programul determină dacă raportul este tipărit sau previzualizat pentru a vedea dacă dialogul VFP este activ. Creăm un câmp pe raport în titlul raportului sau banda antet. Acest câmp nou este modelat după următoarea expresie:

ChangePrintingWindow("Imprimare personalizată","Print.ico","Tipărire contacte...")

Există câteva dezavantaje ale acestei abordări. Primul este motivul cel mai convingător pentru care rămânem de obicei cu dialogul standard. Butonul de comandă de anulare nu este disponibil. Prin urmare, utilizatorul nu are opțiunea de a opri imprimarea. Aceasta poate fi o caracteristică în unele cazuri când raportul trebuie să ruleze indiferent de situație. Al doilea este că numerele paginilor nu sunt afișate pe măsură ce raportul este generat. Putem depăși această problemă prin adăugarea unui câmp în antetul raportului care apelează o metodă personalizată care afișează variabila PageNo în formularul personalizat.
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Cum se schimbă titlul ferestrei de previzualizare la imprimare (Exemplu:

Contacts.scx/frx)

Mulți dezvoltatori nu doresc fereastra standard de previzualizare la imprimare în aplicațiile lor, deoarece titlul formularului de previzualizare afișează numele fișierului raport.

Comanda VFP REPORT FORM are o clauză fereastră care permite dezvoltatorilor să definească un formular în care poate fi afișat raportul. Proprietățile definiției formularului sunt folosite de raport în locul fereastra de previzualizare VFP nativă. Iată un exemplu de cod despre cum folosim această tehnică:

LOCAL loReportForm

LOCAL lcClassPath

LOCAL lcRaport

lcReport = „Contacte”

* 	Creați forma în care se rulează previzualizarea și ascundeți toate celelalte ferestre.

loReportForm = NEWOBJECT("frmPreview", "ch16.vcx")

Ascunde toate ferestrele

* 	Faceți setările ferestrei cu preferințele dvs

CU loReportForm

.Inaltime = _ecran.Inaltime - 30

.Width = _screen.Width - 10

.Name = "loReportForm"

.Caption = .Caption + " - " + lcReport

TASTATURA „{ctrl+f10}”

SE TERMINA CU

FORMULAR DE RAPORT (lcReport) FEREASTRA DE PREVIEW loReportForm

* 	Eliberați formularele și aduceți alte ferestre înapoi

loReportForm.Release()

AFIȚI TOATE WINDOWS

ÎNTOARCERE

Una dintre problemele întâlnite în timpul dezvoltării acestei tehnici a fost că setarea proprietății WindowState din clasă nu contează. Am setat-o la Maximizat, dar forma apare întotdeauna nemaximizată. Am încercat să-l setăm în clasă și am încercat să-l setăm în cod odată ce clasa a fost instanțiată. Deoarece niciuna dintre aceste setări nu a funcționat, am forțat comanda de la tastatură să maximizeze forma.

Clasa de formulare pe care o folosim în mostre se numește frmPreview și se află în biblioteca de clase Ch16.vcx inclusă în fișierele de descărcare pentru dezvoltatori ale capitolului, disponibile la www.hentzenwerke.com.

Singurele proprietăți stabilite în această clasă care nu sunt setările implicite sunt AlwaysOnTop și Caption ale formularului. Există o a doua clasă care este subclasată din clasa frmPreview numită frmPreviewSDI. Acesta este un formular de nivel superior (cunoscut și ca interfață cu un singur document sau SDI) utilizat în același scop, dar pentru o aplicație bazată pe SDI (consultați secțiunea „Cum să afișați o previzualizare a unui raport ca formular de nivel superior” din acest capitol).

Comanda REPORT FORM face ca formularul personalizat să fie vizibil, astfel încât nu este nevoie să gestionați acest lucru în cod. Ascundem toate celelalte ferestre ale aplicației în cazul în care există formulare AlwaysOnTop și le restaurăm când previzualizarea este finalizată.
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Cum să afișați o previzualizare a raportului ca formular la nivel Тор (Exemplu: ContactsSDI. scx/frx)

Visual FoxPro 5.0 a oferit dezvoltatorilor capacitatea de a construi formulare de nivel superior. Aceste formulare rulează în afara desktopului VFP. Visual FoxPro 6.0 a introdus o nouă capacitate cu clauza IN WINDOW pentru comanda de formular REPORT pentru a previzualiza rapoartele într-un formular de nivel superior. Această nouă caracteristică permite dezvoltatorilor care construiesc aplicații SDI să previzualizeze rapoartele fără a expune desktop-ul VFP.

Acest sfat se bazează pe soluția descrisă în secțiunea „Cum se schimbă titlul ferestrei de previzualizare la imprimare”. Trebuie să construiți o clasă de formulare cu aspectul și senzația dorită. Aceasta poate fi o clasă de formulare VFP care este creată cu Form Designer sau în mod programatic prin DEFINE CIAS S. Cheia este să setați proprietatea ShowWindow la 2 - As Top-Level Form.

У Coniaci Raportează Nivel Superior

Contactați IdI

Prenume Nume de familie|bavolio

Previzualizare raport 1001 sfaturi

T3/0W0

(206) 555-9857

Nancy Davo lio

Seattle

Nume

Nume

Oraș

Regiune

Telefon de serviciu

Figura 17.5 Formular de introducere a datelor de nivel superior și previzualizare a raportului de nivel superior

CONTA

Extensie de lucru

Clasa de formulare pe care o folosim în mostre se numește frmPreviewSDI și se află în biblioteca de clase Chló.vcx inclusă în capitolele Developer Download fdes disponibile la www.hentzenwerke.com. Această clasă este o subclasă a formularului frmPreview; Prin urmare, uitați-vă la unele dintre proprietățile implicite stabilite în această clasă.

Conceptul de previzualizare a raportului de nivel superior poate fi continuat cu încă un pas, făcând ca formularul de previzualizare a raportului să fie o formă copil MDI (Multiple Document Interface) a unui alt formular de nivel superior. Proprietatea suplimentară care trebuie setată pentru a distinge! aceasta este proprietatea MDIForm. Seteaza

Proprietatea MDIForm la .t.. Avantajul acestei proprietăți este pentru dezvoltatorii care au o aplicație SDI și au o formă principală în care rulează alte forme MDI. Acest lucru oferă același aspect și senzație ca o aplicație VFP standard, dar mai mult control asupra gestionării evenimentelor/metodei a formularului principal pe care nu îl aveți cu obiectul VFP _screen.

De asemenea, dorim să remarcăm în acest moment că meniul sistemului VFP și fereastra de comandă sunt dezactivate ca și cum ar fi rulat un formular modal atunci când previzualizați rapoartele într-un formular de nivel superior. Microsoft a declarat că acest comportament este prin proiectare. Cauza principală pentru aceasta este că previzualizarea raportului este în bucla proprie în interiorul Visual FoxPro și împiedică funcționarea altor ferestre. Acest lucru este documentat în articolul Q178384 din baza de cunoștințe Microsoft. Soluția este să adăugați un parametru nowait la apelul la FORMULARUL DE RAPORT. Nu suntem siguri că ramificațiile sunt atât de importante, deoarece nu vedem niciodată fereastra de comandă într-o aplicație de producție. Meniul folosit într-o aplicație SDI nu este nici meniul sistemului VFP, dar am crezut că este important să menționăm acest lucru în cazul în care ești declanșat de acest comportament.

Copyright 2000 de către Marcia Akins, Andy Kramek și Rick Schummer Toate drepturile rezervate

Cum să previzualizați mai multe rapoarte simultan (Exemplu MultiReps.scx)

Unul dintre avantajele interesante ale Visual FoxPro este ușurința de a avea mai multe instanțe ale unui formular. Utilizatorii pot compara faptele urmărite despre clientul unul într-un singur formular și despre clientul doi într-un alt formular în cadrul unei aplicații. Această funcție ar fi bună și cu raportarea? Absolut!

Comanda REPORT FORM are această clauză nowait care nu are absolut nimic de-a face cu WAIT WINDOW. Este conceput pentru a permite executarea codului care urmează apelului de raport și lasă raportul disponibil în fereastra de previzualizare a raportului. Pentru a permite utilizatorilor să afișeze mai multe rapoarte și a lăsa fereastra de previzualizare să rămână pe ecran folosind următoarea sintaxă:

FORMULAR DE RAPORT (Nume Raport) PREVIEW ACUM Așteptați

Acest lucru funcționează bine, cu excepția cazului în care doriți să afișați o altă previzualizare a raportului din același raport. Acesta poate fi același nume de raport, dar informații diferite de interogare sau exact același raport, astfel încât utilizatorul să poată privi pagini diferite. Dacă numele raportului este același, dar doriți să alegeți un raport pentru un alt criteriu de interogare, nu puteți utiliza același nume de raport. (Consultați secțiunea „Cum să îi convingeți pe utilizatorii finali să modifice aspectul rapoartelor” din acest capitol pentru o metodă de generare de noi fișiere cu metadate ale rapoartelor pentru a rezolva această problemă.)

Clauza NOWAIT are un efect secundar interesant. Deoarece raportul este terminat și alt cod rulează după FORMULARUL RAPORT, se pare că modul de previzualizare al raportului pierde mediul de date sau cel puțin cursorul la care este legat. Făcând clic pe bara de instrumente de previzualizare pentru a trece la pagina 2 sau mai târziu, apare dialogul de deschidere a tabelului VFP. Acest lucru nu este practic într-o aplicație de producție. Soluția pentru aceasta este utilizarea unei sesiuni de date private pentru raport.
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Figura 17.6 Acesta este un exemplu de două dintre aceleași rapoarte care rulează în două ferestre diferite de previzualizare. Fiecare raport este poziționat pe o pagină diferită.

Dacă nu trebuie să rulați același raport, puteți rula rapoarte toată ziua și toată noaptea în acest mod (cu condiția ca toate să aibă sesiuni de date private) în limitele memoriei și mânerelor fde.
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Cum să eliminați informațiile despre imprimantă. în rapoartele de producție

Există o mulțime de probleme într-un produs la fel de complicat precum Visual FoxPro. Una dintre problemele mai cunoscute este informația codificată de imprimantă care este stocată în metadatele raportului. Problema se învârte în jurul imprimantei utilizate pe măsură ce raportul este elaborat. Informațiile specifice acestei imprimante sunt stocate împreună cu raportul și pot provoca confuzii cu un driver de imprimantă diferit utilizat în mediul aplicației de producție.

Un exemplu este dezvoltarea rapoartelor cu o imprimantă care acceptă duplexarea. Dacă mediul de producție al clientului are imprimante care nu acceptă duplexarea, este posibil să aveți probleme la imprimarea rapoartelor. Același lucru s-ar putea întâmpla dacă imprimanta de dezvoltare are o rezoluție mai mare decât imprimantele de producție.

Soluția implică piratarea datelor imprimantei din metadatele raportului (FRX). Informațiile sunt stocate chiar în prima înregistrare a raportului. Concluzia este că este foarte sigur să goliți atât câmpurile TAG, cât și TAG2. Partea dificilă vine cu câmpul EXPR. Acest câmp trebuie modificat selectiv. În EXPR puteți specifica numărul de copii, orientarea paginii, imprimanta de utilizat și alte câteva lucruri. Comentăm opțiunile DEVICE, DRIVER, OUTPUT, DEFAULT, PRINTQALITY, YRESOLUTION, TTOPTION și DUPLEX pentru toate rapoartele, plasând un „*” în fața fiecărei opțiuni în câmpul EXPR. Restul celor pe care le-am întâlnit (ORIENTARE, DIMENSIUNE HÂRTIE, COPII) în rapoartele noastre nu au avut un efect negativ.

O soluție automată la această problemă este discutată în capitolul Project Hooks, sub o secțiune numită „Cum să eliminați informațiile despre imprimantă din rapoartele VFP”.
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Cum se permite utilizatorilor finali să modifice aspectul rapoartelor (Exemplu

ModiReports.scx)

Suntem siguri că mulți dezvoltatori s-au încrucișat cu un client care este un utilizator suficient de puternic (sau crede că este ) pentru a deschide VFP Report Designer și a-și crea propriile rapoarte. Această secțiune vă va arăta cum puteți expune VFP Report Designer utilizatorilor în timpul execuției, astfel încât aceștia să poată nu numai să modifice rapoartele existente, dar să poată crea și noi rapoarte. Designerul de rapoarte este disponibil în timpul executării - nu veți primi erorile infame „Feature not available” pe care le primiți cu ceilalți designeri.

Una dintre cheile pentru deschiderea funcționalității este să păstrați rapoartele excluse în proiect și să le expediați împreună cu executabilul pentru instalare pe site-ul clientului. Raportul fdes este de obicei inclus în proiectul fde și încorporat în EXE sau APP fde distribuit. Dacă utilizatorii urmează să modifice raportul, aceștia trebuie excluși în proiect, astfel încât să nu fie încorporați în executabil. Aceste surse de raportare fdes sunt incluse în programul de configurare/instalare. În acest fel, utilizatorii pot modifica rapoartele printr-o versiune de dezvoltare a Visual FoxPro sau prin executabilul pe care l-ați creat pentru ei.

Utilizatorii finali vor avea nevoie de cunoștințe tehnice solide despre VFP Report Designer în acest moment. Acest lucru va necesita probabil o anumită pregătire din partea personalului de dezvoltare sau cursuri de formare din afara. Le putem recomanda să cumpere o bucată din această carte pentru a citi cele două capitole despre rapoarte pentru a înțelege mai bine unele dintre complexitățile și abordările pentru rezolvarea problemelor de raportare. Serios, utilizatorii vor avea nevoie de o înțelegere puternică a schemei bazei de date și a Proiectantului de rapoarte pentru a putea folosi această funcționalitate, dar aceasta a fost predeterminată din timp când utilizatorii au solicitat această capacitate ad-hoc.

Figura 17.7 Exemplu de timp de rulare executabil cu setările implicite care modifică un raport

Pentru a crea un nou raport, puteți lua una dintre cele două abordări. Primul este să efectuați o comandă de creare a raportului simplă și simplă. Exemplul de formular (ModiReports.scx) are acest cod în metoda Click butonul de comandă Creare raport. Cealaltă opțiune este să folosiți tehnica discutată în secțiunea „Cum să creați un șablon de raport pentru un proiect” și să rulați cod precum:

CREATE RAPORT fără titlu

Aceasta va afișa șablonul de raport numit Untitled.frx sau va afișa doar aspectul standard de raport VFP standard dacă Untitled.frx nu există.

Stările barelor de instrumente Report Designers (Controale raport, Aspect și paletă de culori) sunt stocate în fișierul de resurse ale aplicației (FoxUser.dbf) în rânduri cu câmpuri de identificare egale cu „TTOOLBAR”. Cel mai simplu mod de a garanta că aplicația dvs. va avea acces la barele de instrumente necesare este să creați un fișier cu resursă curat, să îl setați ca fișier de resurse pentru mediul de dezvoltare, să modificați un raport, să deschideți toate barele de instrumente (prin meniul Vizualizare) și salvați raportul. Salvați fișierul de resurse pentru aplicațiile pe care intenționați să le lansați cu capacitatea de modificare a raportului. Acest fișier va trebui să fie livrat împreună cu aplicația dvs.

O altă metodă este să creați un panou de meniu „Vizualizare” numit _msm_view. În acest meniu adăugați o bară VFP. Numărul barei care trebuie adăugat este _mvi_toolb. Având această opțiune de meniu în aplicația dvs., barele de instrumente vor fi disponibile.

Există pericole în expunerea acestei funcționalități? Într-un cuvânt, absolut! Marea preocupare este expunerea suplimentară a suportului cu clientul. Oricât de cool este această caracteristică, putem spune cu încredere că utilizatorii vor avea probleme prin ruperea codului și veți primi un apel pentru asistență. Argumentul merită, totuși, dacă aveți clienți buni care sunt capabili în acest sens și vă pot economisi timp și energie făcând acele mici ajustări ici și colo.
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Cum să imprimați un câmp de notă cu format text îmbogățit (Exemple

RtfReportl.frx, RtfReport2.frx, ReportsProc.prg)

Unul dintre avantajele interesante ale unui designer de rapoarte grafice este îmbunătățirea fonturilor pentru a face raportul să pară mai plăcut. Una dintre problemele prezentate dezvoltatorilor este schimbarea fonturilor din textul dintr-un câmp. Soluția pentru această situație este de a utiliza formatul de text îmbogățit (RTF) al documentelor. Acest text poate fi stocat într-un câmp de notă (sau general) dintr-un tabel. Acest format poate fi tipărit pe un raport VFP utilizând controlul Picture/ActiveX Bound, care este similar în multe privințe cu OLEBoundControl al unui formular.

Sunt două abordări cu care am lucrat. Prima opțiune (demonstrată în exemplul RTFReport1.frx) este să stocați documentul RTF într-un câmp general. Câmpul general poate fi scos direct pe un raport prin legarea câmpului la controlul raportului. Este bine cunoscut faptul că câmpurile generale VFP se umflă până la punctul în care ocupă mai mult spațiu decât documentele originale, prin urmare mulți dezvoltatori le-au evitat.

Rteteportih: 	Contacte Systempage i

Dezvoltat ca exemplu pentru carte excelentă de foie

1001 de lucruri pe care ai vrut să le știi despre Visual FoxPro

Exemplul 1

Compania este Kirtland Associates, Ine

Îți place că avem un adevărat OZN ѲХсіГГр ІѲ cF the fil» £ё£иТ

Fermare care poate fi salvată într-un document Rich Text Format.

Acest lucru poate fi la îndemână Pentru stering templales cF documente care sunt conduse la rapoartele Fermât.

Text mare

Smdl Г ol

Text Æafic

Bolded Текі

Exemplul 2

Detroit Area FowUser Group

DAFUG se întâlnește în a treia zi de joi a lunii (cu excepția lunii iulie). Royal Oak Pulci c Liorcty este situat la vest de 1-75, la est de Wooduvcrd Avenue și la crie tríe ncrih cf 1-696. Ree partang este cftidlalde în lotul Farmers Market, chiar la est de noi, peste Troy Street. Parkhg contorizat este disponibil în lotul orașului doar pentru cei mai mulți dintre noi.

222East Eleven MieRd.

Royal Oak, Michigan 4S0Ó7

Admiterea la ședințele DAAJG va fi erari:ed gratuită la апусге Fer 1 (aie) întâlnire, după ce vă ieși fie din gOLp (la Icw ccst cF 30 $ pe an, 15 $ Fcr pe jumătate de an) θ' vi se va cere să plătiți 5 USD pentru fiecare întâlnire la care participați. Cei 5 USD vă vor acorda admiterea fără alte privilegii cF mem bere Hip.

Figura 17.8 Raport pe mai multe coloane care demonstrează rezultatul documentelor în format text îmbogățit stocate într-un tabel VFP

A doua abordare (demonstrată în exemplul RtfReport2.frx) este stocarea documentelor RTF într-un fișier memo. Legarea raportului la un câmp de notă care conține cod RTF brut va afișa codul RTF ca text, nu va folosi caracteristicile de formatare. Soluția este să copiați codul RTF într-un fișier temporar și să îl adăugați la un cursor temporar într-un câmp general. Raportul este apoi legat de câmpul general temporar din cursorul temporar. Punerea documentului RTF într-un cursor temporar elimină balonarea generală permanentă a câmpului, deoarece cursorul dispare atunci când este închis. Procesul este după cum urmează:

1. 	Modificați tabelul aplicației, astfel încât să conțină un câmp memo numit mRTFText pentru a păstra documentul RTF brut.

2. 	Completați tabelul cu documentele RTF dorite.

3. 	Adăugați următorul cod în fișierul de procedură:

* ReportsProc.prg

#DEFINE CCRTFFILE "temp.rtf"

* 	Această procedură va salva codul în RTF Memo Field într-un

* 	Fișier document RTF de pe disc, apoi adăugați-l la un fișier temporar

* 	cursorul în câmpul general

**********************

PROCEDURA AppendGenRTF

**********************

LPARAMETER tcMemoFieldName

LOCAL lcRTFTempDirectory

LOCAL lcRTFTempFile

LOCAL lcOldSelect

LOCAL lcOldSafety

lcRTFTempDirectory = ADDBS(SYS(2023))

lcRTFTempFile = lcRTFTempDirectory + ccRTFFILE lcOldSelect = SELECT()

lcOldSafety = SET(„SIGURANȚĂ”)

* 	Copiați nota RTF curentă într-un fișier

OPRITĂ SIGURANȚA

COPIEAZĂ MEMORIA (tcMemoFieldName) ÎN (lcRTFTempFile)

* 	Adăugați la cursorul temp

IF !USED("curRTFGeneral")

CREATE CURSOR curRTFGeneral (gRTF g)

ENDIF

SELECTAȚI curRTFGeneral

ANEXĂ GOL

ANEXĂ GRTF GENERAL DIN (lcRTFTempFile) CLASS WORD. LINK DOCUMENT

SELECTARE (lcOldSelect)

RETURNARE .T.

ENDPROC

* 	Această procedură va elimina (elimina) câmpul general RTF

* 	și ștergeți fișierul RTF temporar

**********************

PROCEDURA BlankGenRTF

**********************

LOCAL lcRTFTempDirectory

LOCAL lcRTFTempFile

LOCAL lcOldSelect

LOCAL lcOldSafety

IF !USED("curRTFGeneral")

* 	Nimic de făcut

ALTE

lcRTFTempDirectory = ADDBS(SYS(2023))

lcRTFTempFile = lcRTFTempDirectory + ccRTFFILE lcOldSelect = SELECT()

lcOldSafety = SET(„SIGURANȚĂ”)

SELECTAȚI curRTFGeneral

OPRITĂ SIGURANȚA

CÂMPURI ALTE gRTF

ȘTERGERE (lcRTFTempFile)

SELECTARE (lcOldSelect)

SETARE SIGURANȚĂ &lcOldSafety

ENDIF

RETURNARE .T.

ENDPROC

4. 	Creați un raport cu un control Picture/ActiveX Bound în banda de detalii și legați-l la câmpul gRTF.

5. 	Adăugați un apel la AppendGenRTF(<RTF Memo fieldname>) în evenimentul OnEntry() al benzii de detalii a raportului. Aceasta populează câmpul general din câmpul memo.

6. 	Adăugați un apel la BlankGenRTF () în Evenimentul OnExit() al benzii de detalii a raportului.

Aceasta elimină documentul RTF tipărit anterior.

7. Asigurându-vă că setați procedura la ReportsProc ADDITIVE, rulați raportul.

8. Fiecare dintre documentele dumneavoastră RTF este tipărit în banda de detalii a raportului dumneavoastră!
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Cum se selectează tava de hârtie

Dacă scrieți un raport utilizând Report Designer, puteți configura ce tavă să utilizați (de fiecare dată când imprimați raportul) alegând File/Page Setup din meniu și apoi apăsând butonul de comandă „Print Setup”. Acolo poți seta ce tavă vrei și se salvează împreună cu raportul. De asemenea, îl puteți modifica în timpul execuției, dacă doriți, sau puteți solicita utilizatorului să seteze setările în timpul execuției prin SYS(1037) .

Dacă nu utilizați Report Designer, atunci trebuie să vă bazați pe configurarea sys(1037). Nu poți schimba cu adevărat configurația imprimantei în mod programat, dar o poți falsifica. Dacă știți că imprimanta se numește „HP LaserJet 4P” în secțiunea Imprimante din Panoul de control și doriți să alegeți Alimentarea manuală, puteți face următoarele:

SETĂ IMPRIMANTA LA NUMELE „HP LaserJet 4P”

IF PRTINFO(7) != 4 && Dacă nu este setat la alimentare manuală

TASTATURA „{TAB}{TAB}{TAB}M{ENTER}”

=SYS(1037)

ENDIF

Acest cod indică VFP să direcționeze ieșirea tipărită către o imprimantă definită în Windows ca „HP LaserJet 4P”, apoi verifică dacă Alimentarea manuală nu este selectată în prezent. Dacă nu, atunci se afișează dialogul sys(1037) (Configurare imprimare) și umple tamponul tastaturii cu apăsările de taste necesare pentru a alege Alimentarea manuală din lista Sursă hârtie. (Presumăm că nu există o altă sursă de hârtie care să înceapă cu „M”.) Una dintre probleme este că acest cod este foarte specific driverului imprimantei și dacă producătorul imprimantei schimbă driverul, este posibil să descoperiți că codul este nu mai functioneaza.
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Alte alternative la Report Designer nativ

Oricât de eficient este Designerul de rapoarte, este un pic neplăcut și are unele limitări. Întrucât trăim într-o lume bazată pe componente, de ce să nu folosim unele dintre celelalte opțiuni disponibile pentru noi? Această secțiune va aborda câteva tehnici pe care le-am folosit în experiența noastră de dezvoltare a aplicațiilor.

Cum să utilizați automatizarea OLE în Word (Exemplu WordAutol.prg, WordAuto2.prg)

Una dintre cele mai ciudate caracteristici pe care le-am văzut vreodată în istoria software-ului a fost un add-in de procesare de text pentru Lotus 123 la mijlocul anilor 1980. Dezvoltatorilor le place să încerce să bage un cuier pătrat printr-o gaură rotundă. Nu există niciun motiv pentru a încerca să împingeți Visual FoxPro să devină un procesor de text atunci când există deja o serie de altele excelente pe piață. Automatizarea Word prin Visual Basic pentru Aplicații (VBA) permite dezvoltatorilor să manipuleze Microsoft Word și poate fi folosită pentru a crea rapoarte.

Această secțiune va încerca să demonstreze câteva elemente de bază despre cum să înlocuiți Word cu Report Designer, nu ca un ghid complet despre manipularea Word. Pentru mai multe despre aceasta, accesați www.hentzenwerke.com și căutați cartea lui Tamar E. Granor și Della Martin. „Automatizare de birou cu Visual FoxPro”.

Exemplele prezentate pentru această secțiune arată câteva concepte de bază pe care trebuie să le implementați atunci când automatizați Word. Primul este să obțineți o referință de obiect la Word însuși cu un apel la

CREATEOBJECT(„Cuvânt.Aplicație”).

Lista 17.2 Acest cod folosește automatizarea pentru a construi un tabel în Word și apoi îl formatează

* 	WordAuto2.prg

LOCAL lowWord

LoDocument LOCAL

LoRange LOCAL

LOCAL loTable

#DEFINE CCCR CHR(13)

#DEFINE CCTAB CHR(9)

DESCHISĂ BAZĂ DE DATE Ch16

UTILIZAȚI v_shortcontactlist ÎN 0

SELECTAȚI v_shortcontactlist

lnRecCount = RECCOUNT("v_shortcontactlist")

lowWord = CREATEOBJECT("Word.Application") lowWord.Visible = .T.

* 	Creați un document nou folosind șablonul implicit „Normal”

loDocument = loWord.Documents.Add()

loRange = loDocument.Range()

* Creați un tabel Word cu 1 rând în plus față de date și 3 coloane loTable = loWord.ActiveDocument.Tables.Add(loRange, lnRecCount + 1, 3) WITH loTable

CU .Rânduri[1]

.Cells [1].Range.InsertAfter(„Nume”)

.Cells[1].Range.Font.Name = „Tahoma”

.Cells[2].Range.InsertAfter(„Companie”)

.Cells[2].Range.Font.Name = „Tahoma”

.Cells[3].Range.InsertAfter(„E-mail”)

.Cells[3].Range.Font.Name = „Tahoma”

.Umbrire.Textură = 100

SE TERMINA CU

SCANĂ

CU .Rânduri[RECNO()+1]

. Cel 1 s [1] . Gamă . InsertAfter (ÃT.T.TRIM(T.ast_Name) + ", " + ALLTRIM(First_name))

.Cells[1].Range.Font.Name = „Tahoma”

.Cells[1].Range.Font.Size = 10

.Celele [2] .Range. InsertAfter (ALLTRIM (Company_Name) )

.Cells[2].Range.Font.Name = „Tahoma”

.Cells[2].Range.Font.Size = 10

.Celele [3] .Range. InsertAfter (ALLTRIM (Nume_E-mail))

.Cells[3].Range.Font.Name = „Tahoma”

.Cells[3].Range.Font.Size = 10

SE TERMINA CU

ENDSCAN

SE TERMINA CU

lcDirectory = FULLPATH(CURDIR())

loWord.ActiveDocument.SaveAs(lcDirectory + „ContList.doc”) loWord.Qui t()

LANSAți loDocRange

LANSAți loTable

LANSAți loRange

Eliberarea documentului

ELIBERĂ lowWord

ÎNTOARCERE

* : EOF : *

Figura 17.9 Demonstrarea datelor VFP prezentate în Microsoft Word

După cum sa demonstrat în exemple, generarea de rapoarte în Word poate determina un dezvoltator să scoată destul de mult cod. Este un proces foarte manual. O modalitate de a evita acest lucru este de a dezvolta unele șabloane Word (.DOT) fdes în avans. Am folosit marcaje, care pot fi introduse cu datele VFP. Marcajele sunt denumite substituenți în interiorul unui șablon de document. Următorul cod este o modalitate de a citi numele marcajelor într-o matrice:

InCountMarks = lowWord. ActiveDocument.Bookmarks.Count()

DIMENSION laMarк(InCountMarks)

PENTRU InCount = 1 LA InCountMarks

laMark[InCount] = lowWord.ActiveDocument.BookMarks(InCount).Name

ENDFOR

Odată ce marcajele sunt determinate din șablon, le puteți potrivi cu datele care trebuie inserate în marcaj. Acest lucru este tratat cu codul după cum urmează:

loWord.ActiveDocument.Marcaje[„City”].Select()

lowWord.Selection.TypeText(IcCity)

Metoda Select evidențiază întregul marcaj, iar metoda TypeText îl suprascrie cu textul transmis. Un cuvânt de precauție - fiecare marcaj trebuie să fie introdus cu date despre caractere, așa că va trebui să îl traduceți în tipul de caracter înainte de a-l introduce în documentul Word.

Cum să ieșiți în alte tipuri de fișiere

Avansarea instrumentelor pentru utilizatorii finali a permis dezvoltatorului de aplicații să se concentreze asupra componentelor care nu sunt de raportare ale dezvoltării aplicațiilor. Din ce în ce mai mulți oameni sunt competenți cu instrumentele Microsoft Office precum Word, Excel și Access. Aceste instrumente au capabilități puternice de graficare și raportare. Există și alte instrumente precum Lotus 123, Quattro Pro și Visio. Dezvoltatorii VFP au câteva moduri de a folosi aceste instrumente. Primul necesită înțelegerea Visual Basic pentru aplicații (VBA) și scrierea codului pentru a automatiza producția. Din păcate, acest concept este disponibil doar pentru instrumentele care au implementat VBA și au expus o interfață care poate fi manipulată prin automatizare. Cea de-a doua și mai generală metodă este de a exporta oricare dintre mai multe aspecte de fișiere comune, astfel încât acestea să poată fi importate în alte instrumente.

Există multe beneficii evidente în utilizarea acestor instrumente pentru utilizatorul final. Cel mai mare este completarea funcțiilor care nu sunt native pentru Visual FoxPro. VFP nu poate fi instrumentul „face totul” pe care ni l-am dori. Trăim astăzi într-o lume de dezvoltare bazată pe componente. Acest lucru permite dezvoltatorilor să adauge funcționalități aplicațiilor, indiferent de caracteristicile oferite de Microsoft în cadrul VFP. Al doilea avantaj/beneficiu al utilizării instrumentelor în care sunt experimentați utilizatorii este că pot crea orice ieșire pe care o doresc inima lor, în limitele instrumentului. Acest lucru le permite, de asemenea, să își reducă investiția financiară în ciclul de dezvoltare a software-ului personalizat și le permite dezvoltatorilor de software să se concentreze asupra părților de dezvoltare a aplicațiilor în care excelează.

Există două comenzi care pot fi folosite pentru a crea fișiere native pentru alte pachete software. Comanda de export generează diferite formate de fișiere de foi de calcul. A doua comandă, copy to, poate genera toate fișierele pe care comanda de export le poate și multe altele. De asemenea, are câteva clauze care vă oferă mai mult control asupra câmpurilor incluse în fișierul exportat.

Toate acestea se rezumă la capacitatea de raportare ad-hoc întotdeauna dorită și completă, pe care utilizatorii noștri o solicită pentru aproape fiecare aplicație pe care o dezvoltăm. Cheia pentru o implementare cu succes a raportării ad-hoc este abstractizarea complexității modelului de date. Aici vederile și interogările stabilite pot fi utile. Având aceste predefinite, elimină educația îmbinărilor exterioare pentru utilizatori. Poate fi puțin frustrant să explici o bază de date normalizată utilizatorilor care înțeleg mai mult decât afacerea, dar nu au idee despre teoria bazelor de date relaționale.

Acesta este motivul pentru care oferim o interfață care permite utilizatorilor să selecteze tipul de date pe care îl doresc și să le exporte într-un număr de formate diferite de fișiere. Formatele cu care lucrăm cel mai frecvent sunt SDF, WK1, CVS, XL5, FOX2X (dbfs de tabel gratuit) și DELIMITAT (virgulă și tab). Acest lucru funcționează cel mai bine împreună cu unul dintre instrumentele comerciale de interogare sau chiar cu un formular de origine care permite utilizatorilor să selecteze anumite date sau vizualizările și interogările predefinite.

Cum se creează text HTML și ASCII (Exemplu HTMLMerge.prg)

FoxPro a avut caracteristica textmerge pentru a genera fișiere text încă de la rădăcinile sale în DOS. Astăzi, dezvoltatorii Visual FoxPro pot folosi această capacitate puternică de ieșire pentru a genera în mod dinamic pagini HTML și fișiere text ASCII.

Există câteva concepte pe care trebuie să le înțelegeți pentru a obține rezultatul îmbinării textului. Comanda SET TEXTMERGE trebuie apelată de două ori. Primul apel activează funcționalitatea textmerge. A doua linie deschide fișierul, care este direcționat:

ACTIVATĂ TEXTMERGE

SETĂ TEXTMERGE LA (tcFileName) ADITIVUL NOSHOW

Clauza ADDITIVE din comanda SET TEXTMERGE vă permite să adăugați rezultate la un fișier existent și

NOSHOW este similar cu clauza NOCONSOLE de pe FORMULARUL DE RAPORT, elimină ecoul de pe desktopul VFP. Fișierul este deschis în același mod ca și deschiderea unui fișier folosind comanda de intrare și ieșire a fișierului de nivel scăzut VFP fopeno . Manipularea fișierului este stocată în variabila de sistem _text. Acest lucru vă oferă capacitatea de a

utilizați, de asemenea, comenzi IO pentru fișiere de nivel scăzut pentru a obține informații pe măsură ce fișierul este generat. În lista de exemplu, folosim funcția fseeko pentru a determina numărul de octeți din fișier.

Lista 17.3 Această listă parțială de cod generează HTML care poate fi vizualizat într-un browser web

* 	HTMLMerge. prg

LPARAMETER tcFileName

#DEFINE ccHTMLTEMPLATEHEAD [TemplateHead. htm]

DACĂ RECCOUNT () > 0

* 	Copiați șablonul în noul fișier pe care îl creăm

COPIEAZĂ FIȘIERUL ccHTMLTEMPLATEHEAD ÎN (tcFileName)

* 	Deschideți un fișier nou și îmbinați restul textului

ACTIVATĂ TEXTMERGE

SETĂ TEXTMERGE LA (tcFileName) ADITIVUL NOSHOW

* 	Titlu

\<p align="center"Xfont face="Tahoma"Xb>1001 de sfaturi Lista de contacte Exemplu HTML \\ </bX/font>

\<pX/p>

\<table border="0" width="900">

* 	Creați un rând HTML pentru toate înregistrările din setul de date

SCANĂ

\ <tr>

\ <tdXfont face="Tahoma" size=2>

\\ <<ALLTRIM(nume)+", " + ALLTRIM(nume)>> </fontX/td>

\ <tdXfont face="Tahoma" size=2> <<ALLTRIM(email_name)>> </fontX/td>

\ <tdXfont face="Tahoma" size=2> <<ALLTRIM(company_name)>> </fontX/td>

\ <tdXfont face="Tahoma" size=2> <<ALLTRIM(city)>> </fontX/td>

\ <tdXfont face="Tahoma" size=2> <<state>> </fontX/td>

\ <tdXfont face="Tahoma" size=2> <<cod poștal>> </fontX/td>

\ </tr>

ENDSCAN

* 	Încheiați subsolul raportului

\</table>

\<pXfont face=" Tahoma" size=" 2" >

\<<DATETIME()>><br>

\<<tcFileName>>

* 	Obțineți numărul de octeți din fișier

lnFileSize = FSEEK(_text,0,2) && Determinați dimensiunea fișierului, atribuiți pnSize

* 	Obțineți dimensiunea fișierului folosind comanda IO pentru fișiere de nivel scăzut

\<br><<"„+tcFileName+” are lungimea de „+ALLTRIM(STR(lnFileSize))+” de octeți.”>> \</font></p>

\</body>

\</html>

* 	Închideți fișierul și dezactivați combinarea textului

SETĂ TEXTMERGE LA

DEZACTIVATĂ TEXTMERGE

ENDIF

Figura 17.10 Demonstrarea datelor VFP care sunt prezentate într-un browser web

În lista de exemplu, folosim o comandă de copiere a fișierului pentru a crea un fișier în același fișier pe care intenționăm să îl generăm folosind TEXTMERGE. Apoi deschidem fișierul cu clauza addhive pentru a adăuga mai multe informații la fișier. Unii dintre cititori ar putea întreba de ce am face asta. Ceea ce am făcut în avans este să creăm o pagină HTML în editorul nostru HTML preferat. Acest lucru ne permite să creăm șabloane folosind comoditatea editorului Ce-Vezi-Este-Ce-Obții (aproape). Această tehnică ne oferă un antet standard, o posibilă imagine de fundal și câteva setări de font pentru toate paginile HTML generate. Același lucru se poate face și pentru un subsol comun. Aceasta înseamnă că doar datele dinamice trebuie codificate și formatate.

Există o serie de produse comerciale care ajută la generarea de rezultate HTML, cum ar fi „WebConnect” al lui Rick Strahl. Dacă aveți nevoi simple, puterea TEXTMERGE va face treaba cu ușurință. Caracteristica TEXTMERGE este, de asemenea, o alternativă la FORMULARUL DE RAPORT ASCII. Deși este nevoie de mai mult efort pentru a formata ieșirea în cod, aveți mult mai mult control asupra formatului atunci când utilizați textmerge în loc de opțiunea asch.

Cum se generează PDF

Adobe Acrobat Portable Document Format (PDF) a câștigat amploare ca format standard pe Web și ca mecanism de schimb pentru ieșiri formatate. Din punct de vedere istoric, generarea de rezultate pentru Web a necesitat formatarea rezultatelor folosind etichete HTML. Acrobat Reader este disponibil gratuit, iar fișierele PDF pot fi vizualizate direct în browser-ul web prin intermediul controlului ActiveX pentru Internet Explorer și al unui add-in pentru Netscape. De asemenea, este independent de platformă, deoarece poate fi vizualizat în

Windows sau pe Macintosh. Fișierele Acrobat sunt, de asemenea, comprimate, ceea ce este ideal pentru rapoartele care trebuie distribuite.

Rapoartele VFP sunt generate ca fișier PDF prin tipărirea directă în driverul de imprimantă PDFWriter. Aceasta necesită o licență completă a Adobe Acrobat, dar vizualizarea rezultatelor necesită doar Adobe Acrobat Reader, care este gratuit. Odată ce imprimați un raport către driverul de imprimantă PDFWriter, vi se solicită să furnizați un nume pentru fișierul PDF. Fișierul se bazează pe motorul Adobe PostScript și ieșirea este așezată exact așa cum ar fi rezultatul în fereastra de previzualizare VFP sau către o imprimantă. Sunteți încă limitat la funcțiile VFP Report Designer, dar vizualizarea și distribuirea raportului sunt îmbunătățite.

Figura 17.11 Acesta este un raport VFP prezentat în Adobe Acrobat

Puteți crea fișiere PDF din orice program care poate fi scos pe o imprimantă. Puteți chiar să combinați Automation cu Word (sau alt program) din VFP, apoi să imprimați această ieșire în driverul de imprimantă PDFWriter.

Odată ce fișierul PDF este creat, acesta poate fi adnotat cu Adobe Exchange. Aceasta este o altă caracteristică a produsului Adobe Acrobat. De câte ori v-ați dorit să aveți posibilitatea de a căuta text într-un raport? Acesta este un alt mare avantaj al acestei tehnici - puteți căuta text în ieșirea raportului. Este destul de rapid, chiar și cu documente mari. Hotlinkurile către site-uri web sunt live și vor porni browserul web implicit atunci când se face clic pe acestea. Aceste caracteristici fac ca revizuirea rapoartelor VFP să fie interactivă.

Toate caracteristicile descrise în această secțiune necesită interacțiunea utilizatorului. Dacă doriți să generați rapoarte în format PDF nesupravegheat, vizitați site-ul web West Wind (www.west-wind.com) pentru a alege cursurile gratuite wwPDF create de Rick Strahl.
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Cum să revizuiți codul de la designerul de rapoarte/etichete (Exemplu

ReportWalkthru.prg, ReportWalkthruOl.frx, cMeta.vcx)

Tot codul de raport pe care îl generăm în VFP Report Designer este stocat într-un fișier de metadate a raportului (.frx). Aceasta nu este altceva decât o masă gratuită VFP. Problema pusă de tabelul de metadate este că nu se poate citi cu ușurință informațiile stocate în rânduri și coloane. Putem răsfoi tabelele de metadate, dar nici acest lucru nu este prietenos pentru dezvoltatori. Această secțiune va prezenta două tehnici de revizuire și documentare a codului de raport.

Metoda preferată de a obține informații din tabelele de metadate este interogarea informațiilor prin instrucțiuni SQL-Select. Veți obține o mai bună înțelegere a metadatelor raportului prin piratarea fișierelor de raport. Hackează întotdeauna copii ale codului sursă de producție. Hackerea fișierului de raport nu este o problemă atât de mare pe cât ar putea suna inițial, deoarece este bine documentată în proiect în directorul HOME()+„Filespec\”. Selectați versiunea corespunzătoare de VFP (adică 60Spec.pjx) și previzualizați rapoartele 60Frx1 și 60Frx2. Există o mulțime de detalii în aceste rapoarte pentru a vă ajuta să construiți un documentator de rapoarte. Desigur, deoarece scriem un capitol despre rapoarte și discutăm despre tehnicile de revizuire a codului și de documentare a rapoartelor dvs., ar fi logic să dăm un exemplu.

Deoarece oamenii drăguți de la Microsoft au fost destul de amabili să documenteze aspectul fișierului de raport, nu vom intra în acest lucru în detaliu. Cu toate acestea, există un câmp în fișier care nu este documentat și care merită o explicație. Acesta este câmpul TimeStamp. Câmpul TimeStamp este un câmp de 32 de biți (comprimat numeric) pe care echipa de dezvoltare FoxPro l-a creat pentru a salva spațiul de fișier din rapoartele și metadatele etichetei (precum și proiectele, formularele, biblioteca de clase vizuale). Acest câmp este utilizat pentru a determina dacă

obiectele trebuie să fie recompilate și sunt actualizate ori de câte ori obiectul din raport sau etichetă este modificat.

Codul pentru procesarea câmpului într-un format pe care îl citim în mod normal ca dată și oră este furnizat în Listare

17.4.

Acest cod poate fi găsit în biblioteca de clase CMeta.vcx ca parte a fișierelor de descărcare pentru dezvoltatori ale capitolului, disponibile la www.hentzenwerke.com.

Lista 17.4 Conversia câmpului TimeStamp într-un fișier FRX este simplă odată ce înțelegeți algoritmul pentru a-l schimba într-un format de dată și oră pe care suntem obișnuiți să le citim

LPARAMETER tnTimeStamp, tcStyle

LOCAL lcRetVal && Datele solicitate returnate din procedură

IF TYPE('tnTimeStamp') != „N” && Timpul trebuie să fie numeric

WAIT WINDOW „Ștampila trecută nu este numerică”

ÎNTOARCERE ""

ENDIF

IF tnTimeStamp = 0 && Timpul este zero până când proiectul este construit

RETURN „Nu este integrat în aplicație”

ENDIF

IF TYPE('tcStyle') != "C" && Stilul implicit de returnare atât la dată, cât și la oră

tcStyle = „DATETIME”

ENDIF

IF !INLIST(UPPER(tcStyle), „DATA”, „TIME”, „DATETIME”)

WAIT WINDOW „Parametrul de stil trebuie să fie DATE, TIME sau DATETIME”

ÎNTOARCERE ""

ENDIF

lnYear = ((tnTimeStamp/(2**25) + 1980))

lnMonth = ((lnYear-INT(lnYear) )*(2**25))/(2**21)

lnDay = ((lnMonth-INT(lnMonth) )*(2**21))/(2**16)

lnHour = ((lnDay-INT(lnDay) )*(2**16))/(2**11)

lnMinute = ((lnHour-INT(lnHour) )*(2**11))/(2**05)

&& Înmulțiți cu doi pentru a corecta problema de trunchiere încorporată

&& la algoritmul de creare (Sursa: Microsoft Tech Support)

lnSecond = ((lnMinute-INT(lnMinute))*(2**05))*2

lcRetVal = ""

DACĂ „DATA” $ UPPER(tcStyle)

lcRetVal = lcRetVal + RIGHT("0"+ALLTRIM(STR(INT(lnMonth))),2) + "/" + ;

RIGHT("0"+ALLTRIM(STR(INT(lnDay))),2) + "/" + ;

RIGHT("0"+ALLTRIM(STR(INT(lnAn))),2)

ENDIF

IF „TIME” $ UPPER(tcStyle)

lcRetVal = lcRetVal + IIF ("DATA" $ UPPER(tcStyle), " ", "")

lcRetVal = lcRetVal + RIGHT("0"+ALLTRIM(STR(INT(lnHour))),2) + ":" + ;

RIGHT("0"+ALLTRIM(STR(INT(lnMinute))),2) + ":" + ;

RIGHT("0"+ALLTRIM(STR(INT(lnSecond))),2)

ENDIF

RETURN lcRetVal

Codul de procesare a metadatelor într-o ieșire care poate fi revizuită poate fi găsit și în ReportWalkThru.prg, care este disponibil ca parte a fișierelor de descărcare pentru dezvoltatori a capitolului, disponibile la www.hentzenwerke.com.

Iată nucleul acestui cod, care procesează metadatele raportului și convertește data.

loMetaDecode = CREATEOBJECT("ctrMetaDecode")

* 	Creați un tabel din formularul de raport deschis, deoarece

* 	Nota de metode va avea unele retururi de transport introduse între ele

* 	metode diferite.

SELECTAȚI *, ;

PADR(loMetaDecode.TimeStamp2Date(timestamp),18) AS cTimeStamp ;

DIN FrxData ;

WHERE !EMPTY(Expr) ;

COMANDĂ DE vpos, hpos;

ÎN CURSOR FrxDataWT

FORMULAR DE RAPORT rptWT.frx NOCONSOLE PREVIEW

Figura 17.12 Acesta este un exemplu de raport generat de programul ReportWalkThru

După cum puteți vedea, scrierea de instrumente rapide care furnizează rezultate face revizuirea raportării în echipă mult mai ușoară decât a solicita dezvoltatorilor să examineze fiecare expresie de obiect prin VFP Report Designer.
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Concluzie

Este adevărat că Visual FoxPro Report Designer are o serie de limitări enervante. Sperăm că sfaturile și tehnicile prezentate în acest capitol vor ajuta utilizatorii să obțină o mai bună prezentare a rezultatelor pe care le solicită. Tehnicile din acest capitol sunt soluții pentru multe dintre limitări, dar sunt, de asemenea, concepute pentru a vă permite să creați un mecanism de raportare mai flexibil pentru utilizatori. Sper că le-ați găsit utile.
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